View source for 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.

{| class="wikitable"
! Lapis !! Pertanyaan !! Alat bukti
|-
| 1 | Arsip bisa dibaca? | <code>gzip -t</code>, <code>tar -tzf</code>
|-
| 2 | Isinya lengkap? | daftar anggota vs <code>find</code> di disk
|-
| 3 | Isinya identik? | <code>diff -r</code>, <code>sha256sum</code>
|-
| 4 | Metadata pulih? | <code>stat</code>, symlink, pemilik
|-
| 5 | 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 ===

{| class="wikitable"
! Angka !! Arti !! Cara mengukur
|-
| RPO | berapa data boleh hilang | selisih waktu backup terakhir dengan kejadian
|-
| RTO | berapa lama boleh mati | stopwatch saat restore penuh
|-
| Keberhasilan | 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 <code>--link-dest</code>.
* '''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 <code>rsync</code>, <code>tar</code>, <code>diff</code>, dan <code>python3</code>. Semua perintah di bawah memakai <code>sudo</code> 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 ===

<syntaxhighlight lang="text">
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
</syntaxhighlight>

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

<syntaxhighlight lang="text">
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
</syntaxhighlight>

=== 🔹 Langkah 2: potret arsip sebelum diuji ===

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

<syntaxhighlight lang="text">
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
</syntaxhighlight>

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? ===

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

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

🧪 '''Uji cepat:''' <code>tar -tzf arsip.tgz > /dev/null; echo $?</code> — 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: <code>tar</code> menulis <code>data/</code>, sedangkan <code>find</code> menulis <code>data</code>.

<syntaxhighlight lang="text">
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
</syntaxhighlight>

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

=== 🔹 Langkah 5: lapis 3, isinya identik? ===

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

<syntaxhighlight lang="text">
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"
</syntaxhighlight>

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

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

=== 🔹 Langkah 6: lapis 4, metadata pulih? ===

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

<syntaxhighlight lang="text">
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=$?"
</syntaxhighlight>

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

{| class="wikitable"
! Yang diperiksa !! Perintah !! Nilai benar
|-
| Mode | <code>stat -c %a</code> | sama dengan asli
|-
| Pemilik | <code>stat -c %U:%G</code> | sama dengan asli
|-
| Symlink | <code>ls -l</code> | masih menunjuk target
|-
| Waktu | <code>stat -c %y</code> | 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.

<syntaxhighlight lang="text">
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
</syntaxhighlight>

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

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

=== 🔹 Langkah 8: ukur RTO, jangan dikira ===

<syntaxhighlight lang="text">
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
</syntaxhighlight>

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 <code>--link-dest</code>, dan lihat inode-nya.

<syntaxhighlight lang="text">
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
</syntaxhighlight>

Kedua baris <code>ls -li</code> 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 ===

{| class="wikitable"
! Pemeriksaan !! Hasil !! Catatan
|-
| Lapis 1 baca | lulus | exit 0
|-
| Lapis 2 daftar | lulus | jumlah sama
|-
| Lapis 3 isi | lulus | hash sama
|-
| Lapis 4 metadata | lulus | mode dan owner sama
|-
| Lapis 5 aplikasi | lulus | integrity ok
|-
| RTO | ..... detik | ukur ulang di produksi
|}

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

<syntaxhighlight lang="text">
sudo rm -rf /srv/lab-restore/restore-1 /srv/lab-restore/restore-2 /srv/lab-restore/rusak-*.tgz
</syntaxhighlight>

=== 🔹 Uji A: arsip terpotong yang terlihat wajar ===

<syntaxhighlight lang="text">
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=$?"
</syntaxhighlight>

Gejalanya: <code>gzip -t</code> keluar 1 dengan pesan <code>unexpected end of file</code>, sedangkan <code>tar</code> 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 ===

<syntaxhighlight lang="text">
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
</syntaxhighlight>

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 <code>--exclude</code> yang ditambahkan setahun lalu dan lupa dihapus.

=== 🔹 Uji C: isi berubah, ukuran dan waktu sama ===

<syntaxhighlight lang="text">
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
</syntaxhighlight>

<code>rsync</code> memakai pemeriksaan cepat berbasis '''ukuran dan waktu modifikasi'''. Karena dua-duanya kamu pertahankan, file yang isinya sudah berubah dianggap tidak berubah. Tambahkan <code>-c</code> 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 <code>--checksum</code> berkala.

=== 🔹 Uji D: restore sebagai user biasa ===

<syntaxhighlight lang="text">
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=$?"
</syntaxhighlight>

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

=== 🔹 Uji E: menulis ke snapshot lama merusak snapshot baru ===

<syntaxhighlight lang="text">
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
</syntaxhighlight>

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

🧪 '''Uji cepat:''' <code>ls -li</code> 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 ===

<syntaxhighlight lang="text">
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
</syntaxhighlight>

GNU tar memulihkan '''keadaan persis''' saat arsip dibuat, termasuk menghapus file yang tidak ada di arsip. File <code>file-lama.txt</code> 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 ===

<syntaxhighlight lang="text">
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
</syntaxhighlight>

Sebelum restore: <code>du</code> menunjukkan 0 dan <code>ls -lh</code> menunjukkan 2,0 GB. Arsipnya kecil karena gzip memampatkan blok kosong. Setelah restore, <code>du</code> 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 <code>-S</code> saat membuat arsip untuk mempertahankan bentuk sparse.

=== 🔹 Uji H: exit 1 belum tentu arsip rusak ===

<syntaxhighlight lang="text">
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=$?"
</syntaxhighlight>

Perintah <code>tar -d</code> 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: <code>0</code> sukses, <code>1</code> ada perbedaan atau ada file berubah saat diarsipkan, <code>2</code> 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 ==

{| class="wikitable"
! Pemeriksaan !! Perintah !! Hasil benar
|-
| Arsip terbaca | <code>gzip -t arsip.tgz</code> | exit 0
|-
| Struktur tar | <code>tar -tzf arsip.tgz</code> | exit 0, daftar tampil
|-
| Jumlah anggota | <code>tar -tzf arsip.tgz &#124; wc -l</code> | sama dengan potret
|-
| Isi identik | <code>diff -r data restore/data</code> | exit 0
|-
| Hash identik | <code>diff hash-asli.txt hash-restore.txt</code> | exit 0
|-
| Metadata | <code>stat -c '%a %U:%G' file</code> | sama dengan asli
|-
| Bandingkan arsip | <code>tar -dzf arsip.tgz -C restore</code> | exit 0
|-
| Integritas DB | <code>pragma integrity_check</code> | <code>ok</code>
|-
| Ruang tujuan | <code>df -h /srv</code> | 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 ==

{| class="wikitable"
! Gejala !! Penyebab !! Tindakan
|-
| <code>unexpected end of file</code> | arsip terpotong | buat ulang, cek ruang disk saat backup
|-
| <code>tar: Unexpected EOF</code> | proses backup dibunuh | cek exit code cron, bukan hanya ada file
|-
| Daftar arsip kurang | <code>--exclude</code> salah | uji manifest tiap bulan
|-
| <code>diff</code> bersih tapi app gagal | izin atau pemilik berubah | restore sebagai root, cek <code>stat</code>
|-
| File jadi milik <code>nobody</code> | restore sebagai user biasa | pakai <code>--same-owner</code> sebagai root
|-
| Mode jadi <code>644</code> | umask saat ekstrak | tambahkan <code>-p</code> atau jalankan sebagai root
|-
| Snapshot lama ikut berubah | hardlink ditulis di tempat | snapshot hanya dibaca, jangan diedit
|-
| File hilang setelah restore | ekstrak incremental ke folder hidup | ekstrak ke folder kosong
|-
| Disk penuh saat restore | sparse file menggelembung | pakai <code>-S</code>, siapkan ruang nyata
|-
| <code>tar</code> exit 1 dianggap rusak | 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 <code>--exclude='*.pdf'</code> 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 <code>--link-dest</code>. 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.''' <code>tar -czf</code> tetap bisa dibuka siapa pun yang punya file. Uji sendiri: <code>tar -tzf arsip.tgz</code> 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: <code>750</code> untuk folder, <code>640</code> untuk file. Hanya grup admin yang boleh membaca.
* Script backup sebaiknya <code>700</code> dan tidak memuat password. Kalau butuh kredensial, pakai file terpisah bermode <code>600</code> atau kunci SSH khusus.
* Folder restore sementara juga berisi data sensitif. Hapus setelah uji, jangan tinggalkan di <code>/tmp</code>.
* 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 ==

* <code>rsync(1)</code> — Debian bookworm: quick check ukuran dan waktu, <code>--checksum</code>, <code>--link-dest</code>, <code>--backup-dir</code>, tabel exit code.
* <code>tar(1)</code> — Debian bookworm: <code>--diff</code>, <code>--verify</code>, <code>--sparse</code>, <code>--same-owner</code>, <code>--numeric-owner</code>, 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.
* <code>gzip(1)</code> — Debian bookworm: opsi <code>-t</code> untuk menguji integritas arsip terkompresi.
* GNU Coreutils, <code>sha256sum(1)</code> — pembuatan dan pemeriksaan manifest checksum.
* <code>diff(1)</code> — Debian bookworm: perbandingan rekursif folder.

[[Category:TKJ]]
[[Category:Linux]]
[[Category:Server]]
[[Category:Backup]]