Restore dan Disaster Recovery

Snapshot mengembalikan kesalahan detik ini, tetapi bencana sejati bekerja lebih kasar: disk yang mati membawa sistemnya, rm -rf yang salah sasaran menghapus tahun kerja, dan ransomware mengunci semuanya. Satu-satunya pertahanan untuk skenario itu adalah backup yang pernah dipulihkan — bukan sekadar disimpan. Chapter penutup section ini melatih keterampilan yang paling jarang dilakukan dan paling menentukan saat dibutuhkan: restore. Kita mulai dari latihan mini yang lengkap dalam satu halaman, verifikasi integritas dengan checksum, lalu prosedur full system restore dan runbook bencana untuk hari terburuk.

Backup yang Belum Diuji Bukan Backup #

Menyalin data itu mudah; yang membedakan backup dari harapan adalah keberhasilan pemulihannya. Tiga hal hanya bisa diketahui lewat uji restore sungguhan: apakah arsip masih bisa dibaca, apakah isinya lengkap, dan berapa lama prosesnya — angka terakhir itulah RTO Anda yang sebenarnya, sering kali jauh dari perkiraan optimis saat merancang jadwal backup. Karena itu aturan kerjanya: setiap backup yang dibuat hari ini harus punya prosedur restore yang bisa dijalankan tanpa membaca dokumentasi panjang, dan prosedur itu harus dilatih berkala sebelum dibutuhkan.

Latihan Mini: Siklus Bencana-Pemulihan Lengkap #

Seluruh siklus backup-restore bisa dilatih dalam satu blok kecil: buat data, catat sidik jarinya, arsipkan, hancurkan datanya, lalu pulihkan dan buktikan hasilnya. Manifest checksum dibuat sebelum bencana — sidik jari yang ditulis setelah data dikembalikan tidak membuktikan apa-apa:

mkdir -p data
printf 'daftar pelanggan bulan januari\n' > data/pelanggan.txt
printf 'invoice nomor 2026-001\n' > data/invoice.txt
printf 'kontrak kerja sama 2026\n' > data/kontrak.txt
sha256sum data/*.txt > MANIFEST
tar --sort=name -czf backup-2026-01-15.tar.gz data
rm -rf data
echo "-- isi folder setelah 'bencana':"
ls
mkdir -p pulih
tar -xzf backup-2026-01-15.tar.gz -C pulih
echo "-- verifikasi hasil restore:"
(cd pulih && sha256sum -c ../MANIFEST)

Output yang Dihasilkan:

-- isi folder setelah 'bencana':
MANIFEST
backup-2026-01-15.tar.gz
-- verifikasi hasil restore:
data/invoice.txt: OK
data/kontrak.txt: OK
data/pelanggan.txt: OK

Bedah baris per barisnya:

1. Baris 6 (sha256sum data/*.txt > MANIFEST): merekam sidik jari setiap file ke dalam manifest — bukti standar yang akan dicek ulang setelah pemulihan.
2. Baris 7 (tar --sort=name -czf ...): membekukan folder data menjadi arsip, dengan urutan isi yang stabil seperti yang kita latih di chapter tar dan Compression .
3. Baris 9 (rm -rf data): simulasinya — data kerja lenyap, yang tersisa hanya manifest dan arsip.
4. Baris 12 (tar -xzf ... -C pulih): memulihkan arsip ke folder karantina pulih, bukan menimpa apa pun di lokasi asal.
5. Baris 14 (sha256sum -c ../MANIFEST): memeriksa setiap file hasil restore terhadap manifest; baris OK adalah bukti bahwa isi arsip identik dengan data sebelum bencana.

Tiga baris OK di akhir output adalah target dari seluruh section ini: data hilang, data kembali, dan kesesuaiannya terbukti. Format pemeriksaannya terdokumentasi di sha256sum(1) ; ingat satu praktik penting dari latihan ini — manifest sebaiknya tersimpan bersama arsipnya, tetapi checksum dibuat dari data yang masih sehat.

Restore Selektif: Satu File dari Arsip #

Bencana paling sering ternyata paling kecil: satu file terhapus atau tertimpa. Mengekstrak seluruh arsip untuk satu file itu boros, padahal tar bisa mengambil satu anggota arsip saja:

mkdir -p data
printf 'daftar pelanggan bulan januari\n' > data/pelanggan.txt
printf 'invoice nomor 2026-001\n' > data/invoice.txt
printf 'kontrak kerja sama 2026\n' > data/kontrak.txt
tar --sort=name -czf backup.tar.gz data
rm data/invoice.txt
tar -xzf backup.tar.gz data/invoice.txt
echo "-- file yang hilang kembali:"
cat data/invoice.txt

Output yang Dihasilkan:

-- file yang hilang kembali:
invoice nomor 2026-001

Bedah baris per barisnya:

1. Baris 6 (rm data/invoice.txt): bencana versi kecil — satu invoice terhapus dari folder kerja.
2. Baris 7 (tar -xzf backup.tar.gz data/invoice.txt): hanya anggota data/invoice.txt yang diekstrak; path anggota ditulis persis seperti yang terlihat pada tar -tzf.

Untuk file kerja yang masih dipakai orang, ekstrak dulu ke folder karantina seperti latihan sebelumnya, periksa isinya, baru pindahkan — menimpa file yang sedang dibuka editor adalah cara baru membuat bencana kedua. Daftar nama anggota arsip selalu bisa dipastikan dulu lewat tar -tzf backup.tar.gz tanpa mengekstrak apa pun.

Verifikasi yang Menangkap Kerusakan Diam-diam #

Checksum tidak hanya untuk hari pemulihan. Bit bisa rusak tanpa suara — media penyimpanan menua, transfer gagal setengah jalan — dan file yang rusak sering tetap terbaca. Manifest yang sama menangkapnya:

mkdir -p data
printf 'daftar pelanggan bulan januari\n' > data/pelanggan.txt
printf 'invoice nomor 2026-001\n' > data/invoice.txt
sha256sum data/*.txt > MANIFEST
printf 'daftar pelanggan bulan januari (ditipu)\n' > data/pelanggan.txt
sha256sum -c MANIFEST 2>&1

Output yang Dihasilkan:

data/invoice.txt: OK
data/pelanggan.txt: FAILED
sha256sum: WARNING: 1 computed checksum did NOT match

Bedah baris per barisnya:

1. Baris 5 (printf ... > data/pelanggan.txt): kerusakan diam-diam — isi file berubah sedikit tanpa sepengetahuan siapa pun, ukurannya nyaris sama.
2. Baris 6 (sha256sum -c MANIFEST 2>&1): pemeriksaan memberontak — FAILED pada pelanggan.txt, OK pada sisanya, lalu sha256sum menutup dengan peringatan dan exit code 1.

Status FAILED itulah alarm yang tidak dimiliki siapa pun tanpa checksum: data terlihat normal, terbaca normal, tetapi tidak lagi data yang dulu Anda simpan. Jadwalkan pemeriksaan periodik atas arsip lama dengan pola yang sama — arsip yang checksum-nya gagal harus dibuat ulang dari sumber yang masih sehat selagi masih ada.

Full System Restore #

Ketika yang mati adalah disk sistem, pemulihan menyangkut lebih dari data: partisi, filesystem, dan bootloader ikut dibangun ulang. Prosedurnya berjalan dari live USB, dan setiap perintahnya menuntut ketelitian karena dijalankan di luar sistem yang biasa menjaga dirinya sendiri:

# dari sesi live USB, sebagai root:
lsblk -f
mkfs.ext4 -L root /dev/nvme0n1p2
mkdir -p /mnt/root-baru
mount /dev/nvme0n1p2 /mnt/root-baru
tar -xzf /mnt/usb/system-full-2026-01-15.tar.gz -C /mnt/root-baru
for d in dev proc sys; do mount --bind /$d /mnt/root-baru/$d; done
chroot /mnt/root-baru

Urutan kerjanya: lsblk -f memetakan disk dan memastikan target mkfs benar — salah sasaran berarti memformat disk yang salah; mkfs.ext4 membangun filesystem baru di atas partisi yang sudah dipartisi ulang bila perlu; mount menyiapkan titik kerja; tar -xzf menumpahkan arsip sistem ke sana; tiga mount --bind menghubungkan direktori pseudo sistem ke dalam pohon baru; dan chroot memindahkan sesi ke dalam sistem yang baru dipulihkan. Di dalam chroot ada dua pekerjaan wajib sebelum reboot: perbarui /etc/fstab dengan UUID partisi baru — UUID lama tercatat di arsip sudah tidak berlaku karena format baru menurunkan UUID segar, topik yang kita bahas tuntas di chapter fstab — lalu pasang ulang bootloader, misalnya grub-install diikuti update-grub pada sistem Debian/Ubuntu, karena tar tidak menyentuh area boot di luar partisi yang diekstrak.

Runbook Bencana #

Saat bencana datang, yang menentukan bukan keberanian melainkan daftar langkah yang ditulis ketika kepala masih dingin. Inti disaster recovery adalah runbook singkat yang menjodohkan skenario dengan sumber pemulihannya:

Dua baris terakhir menuntut disiplin yang kita rancang di chapter Backup Strategies : salinan offsite yang terpisah dari jaringan kantor, idealnya terenkripsi seperti latihan openssl di sana. Tanpa salinan offsite, runbook berhenti di baris ketiga.

Kini kotak penyimpanan dan backup tertutup penuh: partisi dan filesystem dipahami, mount permanen lewat fstab, swap dan LVM memberi ruang napas, RAID menjaga ketersediaan, rsync dan tar menjaga salinan, snapshot menjaga detik terakhir, dan prosedur restore menjamin semuanya bisa dikembalikan. Data yang tersimpan dengan aman adalah data yang siap bergerak — dan pergerakan itulah topik section berikutnya: jaringan, mulai dari pola dasar client-server di Chapter Networking Basics .