Backup Belum Tentu Bisa Restore: Latihan Recovery untuk Home Server

Tombol backup completed memberi rasa aman yang sering terlalu cepat. File arsip bisa saja ada, tetapi database di dalamnya tidak konsisten, kunci enkripsinya hilang, atau langkah pemulihannya cuma diketahui oleh orang yang sedang cuti. Yang dibutuhkan bukan sekadar bukti bahwa backup dibuat, melainkan bukti bahwa layanan bisa dipulihkan.

Untuk home server, aplikasi pribadi, maupun layanan tim kecil, saya lebih suka memisahkan dua pekerjaan: membuat salinan secara rutin dan menjalankan latihan restore di lingkungan terisolasi. Latihan ini tidak perlu mematikan produksi.

Mulai dari apa yang harus kembali hidup

Sebelum memilih tool, tulis inventaris pemulihan. Untuk sebuah aplikasi web sederhana, biasanya meliputi:

• Data: database, berkas unggahan, dan volume persisten.
• Konfigurasi: versi aplikasi, Compose atau manifest deployment, migrasi, dan variabel lingkungan yang diperlukan. Jangan simpan secret dalam arsip yang dapat dibaca publik.
• Akses: kredensial untuk mengambil backup, kunci dekripsi, DNS, dan cara masuk ke server pengganti.
• Verifikasi: beberapa tindakan pengguna yang membuktikan aplikasi berjalan, bukan hanya prosesnya menyala.

Simpan checklist di tempat yang masih bisa diakses saat server utama mati. Jika instruksi restore hanya ada di mesin yang rusak, dokumen tersebut bukan rencana pemulihan.

Tentukan batas kehilangan dan waktu henti

Dua pertanyaan membantu menentukan frekuensi backup:

1. Berapa banyak data yang boleh hilang? Ini adalah Recovery Point Objective (RPO). Jika backup dibuat sekali sehari, jangan menjanjikan kehilangan data maksimal satu jam tanpa mekanisme tambahan.
2. Berapa lama layanan boleh tidak tersedia? Ini adalah Recovery Time Objective (RTO). Angkanya harus mempertimbangkan waktu mengambil arsip, menyiapkan mesin, mengembalikan data, memeriksa aplikasi, dan mengalihkan trafik.

Angka awal boleh berupa target internal. Ubah setelah latihan restore menghasilkan pengukuran nyata; jangan mengklaim RTO tercapai hanya dari durasi menyalin file.

Salinan terpisah bukan sekadar folder lain

Pola 3-2-1 adalah titik awal yang berguna: beberapa salinan, media atau lokasi yang berbeda, dan setidaknya satu salinan di luar mesin utama. Yang lebih penting daripada menghafal angkanya adalah meninjau kegagalan bersama. Backup pada disk kedua yang tetap terpasang di server yang sama mungkin masih terkena salah hapus, ransomware, kebakaran, atau pencurian yang sama.

Pastikan arsip dienkripsi bila memuat data sensitif. Kunci dekripsi perlu dicadangkan secara aman dan diuji aksesnya; backup terenkripsi tanpa kunci adalah data yang tidak dapat dipulihkan. Terapkan retensi sehingga kesalahan yang baru diketahui beberapa hari kemudian tidak menimpa semua versi baik.

Latihan restore yang tidak menyentuh produksi

Gunakan VM, container, atau mesin pengganti dengan jaringan dan kredensial yang dibatasi. Jalankan langkah ini sebagai runbook, bukan improvisasi:

1. Pilih satu titik backup, catat timestamp dan identitas arsipnya.
2. Siapkan lingkungan kosong dengan versi aplikasi dan skema yang sesuai.
3. Pulihkan database dan berkas persisten. Lakukan migrasi hanya jika runbook memang mengharuskannya.
4. Jalankan aplikasi menggunakan secret khusus pengujian jika integrasi eksternal tidak boleh dipanggil. Cegah email, webhook, atau pembayaran sungguhan terkirim dari lingkungan restore.
5. Uji alur nyata: login akun uji, baca satu record, unduh satu unggahan, dan periksa hubungan data penting. Sesuaikan dengan aplikasi—HTTP 200 saja tidak cukup.
6. Catat waktu mulai dan selesai, kesalahan, langkah manual, serta versi yang akhirnya berhasil.
7. Hapus lingkungan uji dan secret sementara sesuai kebijakan retensi.

Jika restore gagal, jangan cukup menulis “backup rusak”. Tentukan apakah yang bermasalah adalah arsip, izin akses, kunci, versi database, urutan migrasi, atau instruksi yang tidak lengkap. Temuan itulah hasil paling berharga dari latihan.

Apa yang perlu dimonitor setiap hari?

Periksa apakah job backup terakhir selesai, ukuran arsip tidak tiba-tiba anjlok, umur salinan terbaru masih dalam batas RPO, dan lokasi off-site dapat diakses. Namun alarm operasional bukan pengganti uji restore berkala: checksum menunjukkan file tidak berubah sejak dihitung, bukan bahwa aplikasi hasil pemulihan bekerja.

Jadwalkan latihan kecil secara berulang. Mulai dari satu layanan paling penting, lalu revisi runbook setelah tiap latihan. Targetnya sederhana: ketika insiden benar-benar datang, langkah berikutnya sudah tertulis dan pernah dikerjakan—bukan baru dipikirkan di tengah kepanikan.