Linux : Praktikum Uji Restore dan Verifikasi Arsip Backup

Arsip backup yang belum pernah dibuka bukan bukti apa-apa. Ia hanya file besar yang kebetulan ada di disk lain. Artikel ini adalah pendamping praktikum dari Linux : Backup Otomatis dengan rsync, tar, dan cron: kalau artikel pagi membangun sistem tiga lapis, artikel sore ini membongkar hasilnya dan membuktikan bahwa isinya benar-benar bisa kembali.

Lab di bawah tidak menambah alat baru. Yang ditambah adalah kebiasaan memeriksa: lima lapis bukti, delapan kerusakan terkendali, dan satu lembar catatan yang bisa ditunjukkan saat ada yang bertanya "backup-nya sudah dites belum?".

🎯 Tujuan

Setelah mengikuti praktikum ini, kamu bisa:

Menjelaskan beda arsip ada dengan arsip terpakai, dan kenapa bedanya penting.
Menguji satu arsip lewat lima lapis bukti, berurutan dari yang paling murah.
Mengukur waktu restore (RTO) dengan stopwatch, bukan dengan perkiraan.
Mengenali delapan gejala arsip rusak yang sering lolos dari pemeriksaan mata.
Mengisi lembar bukti restore yang bisa dilampirkan ke laporan kerja.

📊 Angka penting: satu arsip 10 GB yang gagal dibuka saat dibutuhkan sama nilainya dengan nol byte. Yang dihitung manajemen bukan ukuran arsip, tapi berapa lama layanan boleh mati.

📍 Konteks nyata

Bayangkan tabung pemadam api di lorong sekolah. Tabungnya ada, penanya terpasang, labelnya masih terbaca. Tapi tidak ada yang pernah mengecek tekanan isinya selama dua tahun. Baru saat ada kebakaran kecil di kantin, ketahuan tabungnya kosong.

Backup bekerja dengan cara yang sama. File arsipnya terlihat meyakinkan di file manager: nama berisi tanggal, ukuran puluhan megabyte, ikon zip yang rapi. Yang tidak terlihat adalah apakah isinya lengkap, apakah izin filenya masih benar, dan apakah aplikasi bisa hidup lagi dari data itu.

💡 Tips: anggap arsip backup seperti tabung pemadam: bukan benda yang dipajang, tapi alat yang dijadwalkan dites. Jadwal tesnya bulanan, bukan tahunan.

Karena itu praktikum ini sengaja dibalik. Kamu tidak akan membuat backup baru dari nol. Kamu akan menerima arsip yang "katanya sehat", lalu memeriksanya lapis demi lapis sampai ada yang gagal.

🧠 Konsep singkat

🔹 Lima lapis bukti

Urutannya dari yang paling murah dan paling cepat ke yang paling mahal. Jangan pernah melompat ke lapis bawah sebelum lapis atas lulus.

Lapis	Pertanyaan	Alat bukti
Arsip bisa dibaca? \| `gzip -t`, `tar -tzf`
Isinya lengkap? \| daftar anggota vs `find` di disk
Isinya identik? \| `diff -r`, `sha256sum`
Metadata pulih? \| `stat`, symlink, pemilik
Aplikasi bisa jalan? \| uji integritas data + ukur RTO

Lapis 1 dan 2 bisa selesai dalam hitungan detik. Lapis 5 butuh restore penuh dan bisa memakan puluhan menit. Itu sebabnya lapis 5 hanya dikerjakan setelah empat lapis di atasnya bersih.

🔹 Aturan berhenti di lapis pertama yang gagal

Kalau arsip gagal dibaca di lapis 1, tidak ada gunanya menghitung checksum. Kalau jumlah file kurang di lapis 2, tidak ada gunanya mengukur RTO.

Aturan ini kelihatan sepele, tapi menyelamatkan banyak waktu. Banyak teknisi langsung mengekstrak arsip 40 GB ke folder uji, baru sadar arsipnya terpotong sejak awal. Waktu satu jam hilang untuk membuktikan sesuatu yang bisa diketahui dalam dua detik.

⚠️ Hati-hati: jangan menjadikan "restore berhasil" sebagai satu-satunya ukuran. Restore bisa selesai tanpa error, tapi menghasilkan data dari minggu lalu.

🔹 Tiga angka yang harus diukur

Angka	Arti	Cara mengukur
berapa data boleh hilang \| selisih waktu backup terakhir dengan kejadian
berapa lama boleh mati \| stopwatch saat restore penuh
berapa uji yang lulus \| lembar bukti, bukan ingatan

RPO ditentukan oleh jadwal cron. RTO ditentukan oleh kecepatan disk, ukuran arsip, dan cara restore. Dua-duanya angka, bukan perasaan.

📊 Angka penting: arsip 10 GB di HDD SATA sering butuh 5 sampai 15 menit hanya untuk ekstrak, belum termasuk menyalin balik ke lokasi produksi dan menyalakan layanan. Kalau manajemen minta layanan hidup lagi dalam 5 menit, arsip 10 GB itu tidak memenuhi janji.

🧩 Istilah penting

Restore — mengembalikan data dari arsip ke disk. Beda dengan backup yang menyalin dari disk ke arsip.
Verifikasi — memeriksa arsip tanpa mengembalikannya ke lokasi asli.
Manifest — daftar resmi isi arsip: nama file, ukuran, checksum.
Checksum — sidik jari isi file. Satu byte berubah, nilainya berubah total.
RPO — batas data yang boleh hilang, dihitung dalam waktu.
RTO — batas waktu layanan boleh mati saat dipulihkan.
Sparse file — file yang ukurannya besar tapi isinya sebagian besar kosong. Contoh: image disk 2 GB yang baru terpakai 100 MB.
Hardlink — dua nama file yang menunjuk isi yang sama di disk. Kalau satu ditulis, yang lain ikut berubah.
Snapshot — potret isi folder pada satu waktu tertentu, biasanya dibuat dengan --link-dest.
Incremental — arsip yang hanya memuat file yang berubah sejak arsip sebelumnya, jadi butuh arsip dasar untuk dipulihkan.

🔧 Praktik: uji restore penuh di /srv/lab-restore

Siapkan satu VM Debian atau Ubuntu. Kamu butuh rsync, tar, diff, dan python3. Semua perintah di bawah memakai sudo karena kita menguji pemilik dan izin file.

⚠️ Hati-hati: jangan jalankan praktik ini di server produksi. Kita akan sengaja merusak arsip, dan salah ketik path bisa menghapus data asli.

🔹 Langkah 1: siapkan bahan lab

sudo mkdir -p /srv/lab-restore && cd /srv/lab-restore
sudo mkdir -p data/nilai data/foto data/konfig
sudo dd if=/dev/urandom of=data/nilai/nilai-10.csv bs=1M count=2 status=none
sudo dd if=/dev/urandom of=data/foto/foto-01.jpg bs=1M count=5 status=none
sudo truncate -s 2G data/nilai/gambar.img
printf 'db_host=127.0.0.1\ndb_user=app\n' | sudo tee data/konfig/app.conf > /dev/null
sudo chmod 600 data/konfig/app.conf
sudo ln -s /srv/lab-restore/data/konfig data/konfig-link

Tambahkan satu database kecil dan rekapnya, supaya nanti ada yang bisa diuji "konsisten atau tidak".

sudo python3 - <<'PY'
import sqlite3
c = sqlite3.connect('/srv/lab-restore/data/nilai/nilai.db')
c.execute('create table if not exists nilai (nis text, nilai int)')
c.executemany('insert into nilai values (?,?)',
              [(f'2026{i:03d}', 70 + i % 30) for i in range(1, 201)])
c.commit()
c.close()
PY

sudo python3 - <<'PY'
import sqlite3, csv
c = sqlite3.connect('/srv/lab-restore/data/nilai/nilai.db')
rows = c.execute('select nis, nilai from nilai order by nis').fetchall()
with open('/srv/lab-restore/data/nilai/rekap.csv', 'w', newline='') as f:
    csv.writer(f).writerows(rows)
c.close()
PY

🔹 Langkah 2: potret arsip sebelum diuji

Potret ini yang nanti dipakai sebagai pembanding. Tanpa potret, "berhasil" cuma pendapat.

cd /srv/lab-restore
sudo find data -type f | wc -l
sudo du -sb data
sudo tar -czf arsip.tgz data
sudo sha256sum arsip.tgz | sudo tee arsip.sha256
sudo tar -tzf arsip.tgz | wc -l

Catat tiga angka pertama di kertas: jumlah file, total byte, dan jumlah anggota arsip. Tiga angka inilah yang akan kamu bandingkan terus sampai akhir lab.

🔹 Langkah 3: lapis 1, arsip bisa dibaca?

gzip -t arsip.tgz; echo "gzip exit=$?"
tar -tzf arsip.tgz > /dev/null; echo "tar exit=$?"
tar -tvzf arsip.tgz | wc -l

Keduanya harus keluar dengan kode 0. Perhatikan bahwa tar -tzf membaca seluruh arsip sampai akhir, jadi perintah ini sudah menguji integritas gzip sekaligus struktur tar.

🧪 Uji cepat: tar -tzf arsip.tgz > /dev/null; echo $? — satu baris, dua detik, langsung memberi tahu arsip sehat atau tidak.

🔹 Langkah 4: lapis 2, isinya lengkap?

Bandingkan daftar anggota arsip dengan daftar file di disk. Perhatikan garis miring di akhir nama folder: tar menulis data/, sedangkan find menulis data.

sudo tar -tzf arsip.tgz | sed 's#/$##' | sort > daftar-arsip.txt
sudo find data | sort > daftar-disk.txt
diff daftar-arsip.txt daftar-disk.txt && echo "daftar sama"
wc -l daftar-arsip.txt daftar-disk.txt

Kalau jumlahnya beda, jangan lanjut. Selisih satu file bisa berarti file penting (misalnya app.conf) tidak pernah masuk arsip.

🔹 Langkah 5: lapis 3, isinya identik?

Restore ke folder baru, lalu bandingkan isi. File gambar.img dikecualikan dari hashing karena 2 GB data kosong hanya memperlambat lab tanpa menambah pelajaran.

cd /srv/lab-restore
sudo mkdir -p restore-1
sudo tar -xzf arsip.tgz -C restore-1

sudo diff -r data restore-1/data; echo "diff exit=$?"

sudo find data -type f ! -name gambar.img -exec sha256sum {} + | sort -k2 > hash-asli.txt
(cd restore-1 && sudo find data -type f ! -name gambar.img -exec sha256sum {} + | sort -k2) > hash-restore.txt
sudo diff hash-asli.txt hash-restore.txt && echo "isi identik"

diff membandingkan isi dan melaporkan file yang hanya ada di satu sisi. sha256sum memberi bukti yang lebih kuat: kalau dua file punya hash sama, isinya sama.

💡 Tips: simpan hash-asli.txt bersama arsipnya. Bulan depan kamu tidak perlu punya data asli untuk membuktikan arsip masih utuh, cukup jalankan sha256sum -c terhadap manifest itu.

🔹 Langkah 6: lapis 4, metadata pulih?

Isi sama belum tentu bisa dipakai. File konfigurasi yang tadinya 600 bisa berubah menjadi 644, dan file milik www-data bisa berubah menjadi milik user yang melakukan restore.

sudo stat -c '%a %U:%G %s %n' data/konfig/app.conf
sudo stat -c '%a %U:%G %s %n' restore-1/data/konfig/app.conf
sudo ls -l restore-1/data/konfig-link
sudo tar -dzf arsip.tgz -C restore-1; echo "compare exit=$?"

Perhatikan tiga hal: mode file, pemilik, dan symlink. Kalau symlink berubah menjadi file biasa berisi teks path, aplikasi yang membacanya akan bingung.

Yang diperiksa	Perintah	Nilai benar
`stat -c %a` \| sama dengan asli
`stat -c %U:%G` \| sama dengan asli
`ls -l` \| masih menunjuk target
`stat -c %y` \| sama dengan asli

🔹 Langkah 7: lapis 5, aplikasi bisa jalan?

Di sini kamu berhenti memeriksa file dan mulai memeriksa makna file. Database bisa utuh sebagai file tapi rusak sebagai database. Rekap bisa lengkap tapi tidak cocok dengan isi database.

sudo python3 - <<'PY'
import sqlite3
p = '/srv/lab-restore/restore-1/data/nilai/nilai.db'
c = sqlite3.connect(p)
print('integrity :', c.execute('pragma integrity_check').fetchone()[0])
print('baris db  :', c.execute('select count(*) from nilai').fetchone()[0])
c.close()
PY

sudo wc -l < restore-1/data/nilai/rekap.csv

Hasil yang diharapkan: ok, 200, dan 200. Kalau angka terakhir beda, artinya ada dua sumber data yang pernah ditulis di waktu berbeda dan arsipmu memotret keadaan yang tidak konsisten.

📊 Angka penting: pragma integrity_check memeriksa struktur halaman database, bukan kebenaran isinya. Database yang lulus pemeriksaan tetap bisa berisi nilai yang salah.

🔹 Langkah 8: ukur RTO, jangan dikira

cd /srv/lab-restore
sudo mkdir -p restore-2
start=$(date +%s)
sudo tar -xzf arsip.tgz -C restore-2
echo "RTO tar: $(( $(date +%s) - start )) detik"
df -h /srv

Catat angkanya. Kalau restore butuh 8 menit, maka RTO layananmu minimal 8 menit ditambah waktu menyalin balik ke lokasi asli dan menyalakan ulang layanan.

⚠️ Hati-hati: mengukur RTO di VM lab yang disknya kosong akan memberi angka terlalu optimis. Disk produksi yang sibuk bisa dua sampai tiga kali lebih lambat.

🔹 Langkah 9: uji snapshot hardlink

Sekarang buat snapshot pertama, lalu snapshot kedua dengan --link-dest, dan lihat inode-nya.

sudo rsync -a data/ /srv/lab-restore/snap-1/
sudo rsync -a --delete --link-dest=/srv/lab-restore/snap-1 data/ /srv/lab-restore/snap-2/
sudo ls -li snap-1/data/nilai/rekap.csv snap-2/data/nilai/rekap.csv
sudo du -sh snap-1 snap-2

Kedua baris ls -li menunjukkan nomor inode yang sama. Artinya dua "versi backup" berbagi isi yang sama di disk, sehingga snapshot kedua hampir tidak memakan ruang. Itu fitur, sekaligus jebakan yang akan kamu buka di Uji E.

🔹 Langkah 10: isi lembar bukti dan bersihkan

Pemeriksaan	Hasil	Catatan
lulus \| exit 0
lulus \| jumlah sama
lulus \| hash sama
lulus \| mode dan owner sama
lulus \| integrity ok
..... detik \| ukur ulang di produksi

Setelah selesai, bersihkan folder lab. Jangan biarkan arsip uji menumpuk dan mengaburkan arsip yang sungguhan.

sudo rm -rf /srv/lab-restore/restore-1 /srv/lab-restore/restore-2 /srv/lab-restore/rusak-*.tgz

🔹 Uji A: arsip terpotong yang terlihat wajar

cd /srv/lab-restore
cp arsip.tgz rusak-A.tgz
truncate -s -4096 rusak-A.tgz
ls -l rusak-A.tgz arsip.tgz
gzip -t rusak-A.tgz; echo "gzip exit=$?"
tar -tzf rusak-A.tgz > /dev/null; echo "tar exit=$?"

Gejalanya: gzip -t keluar 1 dengan pesan unexpected end of file, sedangkan tar keluar 2. Yang penting bukan pesannya, tapi kenyataan bahwa ukuran file di file manager tidak memberi tahu apa pun. Selisih 4 KB dari 7 MB tidak terlihat oleh mata.

🔹 Uji B: arsip bisa dibuka tapi isinya kurang

sudo tar -czf rusak-B.tgz --exclude='*.jpg' data
sudo tar -tzf rusak-B.tgz | grep -c jpg
sudo tar -tzf rusak-B.tgz | wc -l

Lapis 1 lulus, lapis 2 gagal. Inilah bentuk kegagalan backup yang paling sering terjadi di dunia nyata: bukan arsip rusak, tapi arsip yang tidak pernah memuat file yang dibutuhkan. Penyebabnya biasanya satu baris --exclude yang ditambahkan setahun lalu dan lupa dihapus.

🔹 Uji C: isi berubah, ukuran dan waktu sama

cd /srv/lab-restore
sudo sh -c 'printf X | dd of=data/nilai/nilai-10.csv bs=1 seek=100 conv=notrunc status=none'
sudo touch -r snap-1/data/nilai/nilai-10.csv data/nilai/nilai-10.csv
sudo rsync -an -i data/ snap-3/ | grep nilai-10 || echo "quick check: dilewati"
sudo rsync -anc -i data/ snap-4/ | grep nilai-10

rsync memakai pemeriksaan cepat berbasis ukuran dan waktu modifikasi. Karena dua-duanya kamu pertahankan, file yang isinya sudah berubah dianggap tidak berubah. Tambahkan -c dan file itu muncul.

⚠️ Hati-hati: ini bukan bug, ini desain. Konsekuensinya: arsip bisa "sukses" setiap malam tapi memuat versi lama satu file. Untuk data yang sensitif, jadwalkan --checksum berkala.

🔹 Uji D: restore sebagai user biasa

sudo mkdir -p /tmp/restore-nobody
sudo chown nobody /tmp/restore-nobody
sudo -u nobody tar -xzf /srv/lab-restore/arsip.tgz -C /tmp/restore-nobody
sudo stat -c '%a %U:%G %n' /srv/lab-restore/data/konfig/app.conf
sudo stat -c '%a %U:%G %n' /tmp/restore-nobody/data/konfig/app.conf
sudo diff -r /srv/lab-restore/data /tmp/restore-nobody/data; echo "diff exit=$?"

Untuk user biasa, GNU tar memakai --no-same-owner dan --no-same-permissions secara bawaan. Hasilnya: file 600 bisa jadi 644, dan pemiliknya berubah menjadi nobody. diff tetap melaporkan tidak ada perbedaan, karena diff membandingkan isi, bukan izin.

🔹 Uji E: menulis ke snapshot lama merusak snapshot baru

sudo sh -c 'echo "baris-rusak" >> /srv/lab-restore/snap-1/data/nilai/rekap.csv'
sudo tail -1 /srv/lab-restore/snap-2/data/nilai/rekap.csv
sudo ls -li /srv/lab-restore/snap-1/data/nilai/rekap.csv /srv/lab-restore/snap-2/data/nilai/rekap.csv

Baris yang kamu tambahkan ke snapshot lama langsung muncul di snapshot baru, karena keduanya menunjuk isi yang sama. Perintah echo >> menulis di tempat, bukan membuat file baru.

🧪 Uji cepat: ls -li pada file yang sama di dua snapshot. Inode sama dan kolom link lebih dari 1 berarti isi dibagi, bukan disalin.

🔹 Uji F: arsip incremental menghapus file di folder tujuan

cd /srv/lab-restore
sudo mkdir -p inc/data && sudo cp -a data/nilai/rekap.csv inc/data/
sudo tar -czf inc-0.tgz -g /srv/lab-restore/inc.snar -C inc data
sudo touch inc/data/baru.txt
sudo tar -czf inc-1.tgz -g /srv/lab-restore/inc.snar -C inc data

sudo mkdir -p inc-restore/data && sudo touch inc-restore/data/file-lama.txt
sudo tar -xzf inc-0.tgz -g /dev/null -C inc-restore
sudo tar -xzf inc-1.tgz -g /dev/null -C inc-restore
sudo ls inc-restore/data

GNU tar memulihkan keadaan persis saat arsip dibuat, termasuk menghapus file yang tidak ada di arsip. File file-lama.txt hilang. Karena itu ekstraksi incremental hanya boleh ke folder kosong, bukan ke folder produksi yang sedang dipakai.

🔹 Uji G: sparse file, arsip kecil tapi restore butuh ruang penuh

cd /srv/lab-restore
du -h data/nilai/gambar.img
ls -lh data/nilai/gambar.img
sudo tar -czf arsip-sparse.tgz data/nilai/gambar.img
ls -lh arsip-sparse.tgz
sudo mkdir -p restore-sparse
sudo tar -xzf arsip-sparse.tgz -C restore-sparse
du -h restore-sparse/data/nilai/gambar.img

Sebelum restore: du menunjukkan 0 dan ls -lh menunjukkan 2,0 GB. Arsipnya kecil karena gzip memampatkan blok kosong. Setelah restore, du melonjak ke 2,0 GB karena tar menulis semua blok nol ke disk.

📊 Angka penting: arsip 2 GB data kosong bisa menjadi file beberapa megabyte, tapi restore-nya menulis 2 GB nyata. Kalau partisi tujuan hanya punya 1 GB sisa, restore gagal di detik terakhir setelah menunggu lama. Tambahkan -S saat membuat arsip untuk mempertahankan bentuk sparse.

🔹 Uji H: exit 1 belum tentu arsip rusak

cd /srv/lab-restore
sudo tar -dzf arsip.tgz -C restore-2; echo "compare exit=$?"
sudo touch restore-2/data/nilai/rekap.csv
sudo tar -dzf arsip.tgz -C restore-2; echo "compare exit=$?"

Perintah tar -d membandingkan arsip dengan isi disk. Kalau ada yang berbeda, ia keluar dengan kode 1 dan menyebut file yang dimaksud. Kode 1 berarti "ada perbedaan", bukan "arsip fatal rusak". Kode 2 baru berarti kegagalan serius.

💡 Tips: bedakan tiga kode keluaran tar: 0 sukses, 1 ada perbedaan atau ada file berubah saat diarsipkan, 2 gagal fatal. Membaca kode ini mencegah kamu menghapus arsip sehat hanya karena salah tafsir.

🏭 Dipakai di dunia kerja

Sekolah: server ujian berbasis komputer harus bisa hidup lagi sebelum jam ujian berikutnya. Guru tidak butuh tahu rsync, tapi butuh kepastian bahwa data peserta tidak hilang saat disk server mati.
Kantor distributor: faktur dan surat jalan adalah bukti hukum. Uji restore bulanan membuktikan arsip faktur tiga tahun masih bisa dibuka saat auditor datang.
Klinik dan apotek: rekam medis punya batas retensi yang diatur. Restore yang tidak pernah diuji berarti risiko kehilangan riwayat pasien sekaligus masalah kepatuhan.
ISP dan warnet: data billing adalah uang. RTO dihitung dalam menit, karena setiap menit layanan mati berarti pelanggan tidak bisa membeli paket.
Industri manufaktur: log mesin dipakai untuk investigasi kecelakaan kerja. Arsip log yang tidak bisa dipulihkan membuat investigasi berhenti di "kata operator".
Studio dan lab kreatif: aset proyek klien sering lebih mahal daripada perangkatnya. Snapshot hardlink memungkinkan banyak versi tanpa menggandakan pemakaian disk.

✅ Verifikasi

Pemeriksaan	Perintah	Hasil benar
`gzip -t arsip.tgz` \| exit 0
`tar -tzf arsip.tgz` \| exit 0, daftar tampil
`tar -tzf arsip.tgz \| wc -l` \| sama dengan potret
`diff -r data restore/data` \| exit 0
`diff hash-asli.txt hash-restore.txt` \| exit 0
`stat -c '%a %U:%G' file` \| sama dengan asli
`tar -dzf arsip.tgz -C restore` \| exit 0
`pragma integrity_check` \| `ok`
`df -h /srv` \| cukup untuk ukuran nyata

🧪 Uji cepat: jalankan empat perintah pertama sebagai satu baris di cron bulanan. Kalau salah satu keluar bukan 0, kirim email ke admin. Itu sudah cukup untuk menangkap mayoritas kegagalan arsip.

⚠️ Kesalahan umum & troubleshooting

Gejala	Penyebab	Tindakan
arsip terpotong \| buat ulang, cek ruang disk saat backup
proses backup dibunuh \| cek exit code cron, bukan hanya ada file
`--exclude` salah \| uji manifest tiap bulan
izin atau pemilik berubah \| restore sebagai root, cek `stat`
restore sebagai user biasa \| pakai `--same-owner` sebagai root
umask saat ekstrak \| tambahkan `-p` atau jalankan sebagai root
hardlink ditulis di tempat \| snapshot hanya dibaca, jangan diedit
ekstrak incremental ke folder hidup \| ekstrak ke folder kosong
sparse file menggelembung \| pakai `-S`, siapkan ruang nyata
salah tafsir kode \| bedakan 1 (beda) dan 2 (fatal)

🔥 Kasus nyata: sebuah SMK di Jawa Timur mencadangkan nilai setiap malam selama setahun. Arsip selalu muncul di NAS dengan ukuran wajar, jadi tidak ada yang curiga. Saat HDD server mati dua hari sebelum rapor, restore gagal di menit pertama: arsip terpotong sejak bulan ketiga karena NAS penuh dan cron mati diam-diam. Nilai satu semester direkap manual dua minggu.

🔥 Kasus nyata: kantor distributor alat kesehatan mencadangkan faktur dengan rsync setiap jam. Staf IT merapikan script dan menambahkan --exclude='*.pdf' agar lebih cepat. Enam minggu arsip tetap terbentuk dan berukuran besar, tapi seluruh faktur tidak ada di dalamnya. Ketahuan saat auditor meminta faktur bulan lalu. Yang diuji bukan ada tidaknya arsip, tapi daftar isinya.

🔥 Kasus nyata: warnet dengan dua snapshot harian memakai --link-dest. Teknisi magang membuka snapshot kemarin untuk "melihat isi file log", lalu menekan simpan dari editor teks. Karena file itu hardlink, snapshot hari ini ikut berubah. Dua hari kemudian laporan pelanggan yang seharusnya ada di snapshot hilang, dan tidak ada yang bisa menjelaskan sebabnya sampai inode diperiksa.

🔐 Catatan keamanan & etika

Arsip backup berisi data pribadi: nilai siswa, rekam medis, faktur, dan log akses. Perlakukan seperti data aslinya, bukan seperti file sampah.
Kompresi bukan enkripsi. tar -czf tetap bisa dibuka siapa pun yang punya file. Uji sendiri: tar -tzf arsip.tgz langsung menampilkan nama file tanpa kunci.
Kalau memakai enkripsi, simpan kunci di tempat terpisah dari arsip. Kunci yang hilang mengubah arsip menjadi sampah permanen.
Batasi izin folder arsip: 750 untuk folder, 640 untuk file. Hanya grup admin yang boleh membaca.
Script backup sebaiknya 700 dan tidak memuat password. Kalau butuh kredensial, pakai file terpisah bermode 600 atau kunci SSH khusus.
Folder restore sementara juga berisi data sensitif. Hapus setelah uji, jangan tinggalkan di /tmp.
Etika: saat menguji restore di server bersama, gunakan salinan data, bukan data hidup. Membaca arsip orang lain tanpa izin sama dengan membaca data aslinya.
Restore menghapus dan menimpa file. Pastikan path tujuan sudah benar sebelum menekan Enter, karena tidak ada undo.

📌 Kesimpulan

Backup terdiri dari dua pekerjaan yang sering dianggap satu: menyalin, dan membuktikan. Artikel pagi ini menyelesaikan yang pertama. Praktikum ini menyelesaikan yang kedua.

Kalau hanya satu kebiasaan yang bisa kamu bawa dari sini, ambil yang ini: setiap arsip harus pernah dibuka, dihitung, dan diukur waktu kembalinya. Selebihnya hanya variasi alat.

Langkah berikutnya: jalankan empat perintah verifikasi di bagian bagian Verifikasi|Verifikasi sebagai cron bulanan, lalu simpan hasilnya di satu file teks. Arsip yang punya riwayat pemeriksaan jauh lebih berharga daripada arsip yang hanya punya nama bagus.

🔗 Materi terkait

Linux : Backup Otomatis dengan rsync, tar, dan cron — artikel konsep pendamping: sistem tiga lapis dan pembuatan arsipnya.
Linux : Log dan journalctl untuk Troubleshooting — membaca jejak kegagalan backup di journal dan syslog.
Linux : Disk, Partisi, dan Filesystem (Mount dan fstab) — kenapa ruang dan titik mount menentukan keberhasilan restore.
Linux : Praktikum Mount, fsck, dan Perluasan Filesystem — menambah ruang saat partisi tujuan hampir penuh.
Linux: Cron Job — dasar penjadwalan untuk verifikasi bulanan.
Mikrotik : Praktikum Restore Backup dan Import Export — konsep restore di perangkat jaringan, untuk perbandingan.

📚 Referensi

rsync(1) — Debian bookworm: quick check ukuran dan waktu, --checksum, --link-dest, --backup-dir, tabel exit code.
tar(1) — Debian bookworm: --diff, --verify, --sparse, --same-owner, --numeric-owner, return value 0/1/2.
GNU Tar Manual, bagian 5.2 "Using tar to Perform Incremental Dumps" — snapshot file, level 0 dan level 1, perilaku ekstraksi yang menghapus file.
gzip(1) — Debian bookworm: opsi -t untuk menguji integritas arsip terkompresi.
GNU Coreutils, sha256sum(1) — pembuatan dan pemeriksaan manifest checksum.
diff(1) — Debian bookworm: perbandingan rekursif folder.

Lapis	Pertanyaan	Alat bukti
Arsip bisa dibaca? \| `gzip -t`, `tar -tzf`
Isinya lengkap? \| daftar anggota vs `find` di disk
Isinya identik? \| `diff -r`, `sha256sum`
Metadata pulih? \| `stat`, symlink, pemilik
Aplikasi bisa jalan? \| uji integritas data + ukur RTO

Yang diperiksa	Perintah	Nilai benar
`stat -c %a` \| sama dengan asli
`stat -c %U:%G` \| sama dengan asli
`ls -l` \| masih menunjuk target
`stat -c %y` \| sama dengan asli

Pemeriksaan	Hasil	Catatan
lulus \| exit 0
lulus \| jumlah sama
lulus \| hash sama
lulus \| mode dan owner sama
lulus \| integrity ok
..... detik \| ukur ulang di produksi

Pemeriksaan	Perintah	Hasil benar
`gzip -t arsip.tgz` \| exit 0
`tar -tzf arsip.tgz` \| exit 0, daftar tampil
`tar -tzf arsip.tgz \| wc -l` \| sama dengan potret
`diff -r data restore/data` \| exit 0
`diff hash-asli.txt hash-restore.txt` \| exit 0
`stat -c '%a %U:%G' file` \| sama dengan asli
`tar -dzf arsip.tgz -C restore` \| exit 0
`pragma integrity_check` \| `ok`
`df -h /srv` \| cukup untuk ukuran nyata

Gejala	Penyebab	Tindakan
arsip terpotong \| buat ulang, cek ruang disk saat backup
proses backup dibunuh \| cek exit code cron, bukan hanya ada file
`--exclude` salah \| uji manifest tiap bulan
izin atau pemilik berubah \| restore sebagai root, cek `stat`
restore sebagai user biasa \| pakai `--same-owner` sebagai root
umask saat ekstrak \| tambahkan `-p` atau jalankan sebagai root
hardlink ditulis di tempat \| snapshot hanya dibaca, jangan diedit
ekstrak incremental ke folder hidup \| ekstrak ke folder kosong
sparse file menggelembung \| pakai `-S`, siapkan ruang nyata
salah tafsir kode \| bedakan 1 (beda) dan 2 (fatal)