Uji Restore Backup Sebelum Data Benar-benar Hilang
Backup baru terbukti saat berhasil dipulihkan. Begini cara menjalankan uji restore website dan database, mengukur RTO dan RPO, serta mencatat hasilnya.
Jawaban singkat
Uji restore adalah latihan memulihkan backup ke server uji secara terjadwal. Ukur RPO (data yang hilang) dan RTO (waktu sampai pulih), catat hasilnya, dan perbaiki penyebab gagal seperti backup tidak lengkap, kunci enkripsi hilang, atau versi tidak cocok.
Daftar isi
Notifikasi backup masuk setiap pagi: "Job completed successfully". Selama berbulan-bulan tidak ada yang membukanya lebih jauh. Lalu suatu hari database website rusak, kamu mengambil file backup terbaru, dan baru saat itu ketahuan bahwa file dump-nya kosong, atau arsipnya terenkripsi dengan kunci yang tidak ada yang tahu disimpan di mana.
Status "berhasil" di aplikasi backup hanya berarti proses selesai tanpa error yang terdeteksi, bukan berarti datanya bisa dipulihkan. Satu-satunya cara memastikannya adalah benar-benar memulihkan backup itu, secara terjadwal, sebelum kamu terpaksa melakukannya dalam keadaan panik.
RTO dan RPO: dua angka yang perlu kamu tentukan dulu
Sebelum menguji, tentukan apa yang dianggap "lulus". Dua ukuran yang lazim dipakai adalah RPO dan RTO.
RPO (Recovery Point Objective) adalah batas data yang boleh hilang, diukur dalam waktu. Kalau backup database berjalan setiap malam pukul 01.00 dan server rusak pukul 17.00, data selama 16 jam terakhir hilang. Bila bisnismu tidak sanggup kehilangan pesanan sehari penuh, RPO harian terlalu longgar dan kamu butuh backup lebih sering atau replikasi.
RTO (Recovery Time Objective) adalah target waktu dari mulai rusak sampai layanan kembali berjalan. Waktu ini mencakup menyiapkan server, mengunduh backup, memulihkan file dan database, mengubah DNS bila perlu, dan mengecek bahwa semuanya berfungsi.
Kedua angka ini keputusan bisnis, bukan teknis. Tanyakan ke pemilik usaha: berapa lama toko online boleh mati, dan berapa banyak transaksi yang boleh hilang. Jawabannya menjadi target uji restore.
Cara menjalankan latihan restore
Siapkan server uji yang terpisah dari produksi. Bisa VPS kecil yang dinyalakan hanya saat latihan, atau container di laptop untuk website sederhana. Yang penting, pemulihan tidak menimpa data produksi dan server uji tidak bisa diakses publik.
Untuk website, ambil backup file terbaru dari lokasi penyimpanan yang sesungguhnya, bukan dari salinan lokal yang kebetulan ada. Ekstrak ke server uji, sesuaikan konfigurasi koneksi database, lalu buka website lewat alamat sementara atau file hosts. Cek halaman utama, halaman produk, upload gambar, dan login admin.
Untuk database, pulihkan dump ke server database dengan versi yang sama atau sangat dekat dengan produksi. Setelah itu jangan berhenti di "tidak ada error". Hitung jumlah baris di tabel penting, misalnya pesanan dan pelanggan, lalu bandingkan dengan produksi pada waktu backup. Cek juga data terbaru yang ada di backup untuk mengukur RPO sebenarnya.
Mulai stopwatch sejak kamu memutuskan "kita pulihkan" sampai website uji bisa dipakai normal. Angka itu adalah RTO aktualmu, dan sering lebih lama dari perkiraan, terutama pada percobaan pertama.
Terakhir, matikan atau hapus server uji setelah selesai, karena isinya adalah salinan data asli.
Untuk latihan pertama, jangan langsung mencoba pemulihan penuh semua sistem. Pilih satu website atau satu database yang paling penting, jalankan sampai tuntas, lalu catat setiap langkah yang ternyata tidak terdokumentasi. Catatan itu menjadi bahan perbaikan sebelum latihan berikutnya yang cakupannya lebih luas.
Kenapa backup sering gagal dipulihkan?
Penyebabnya jarang canggih. Tabel berikut merangkum yang paling sering ditemukan saat latihan.
| Penyebab gagal | Contoh gejala | Cara mencegah |
|---|---|---|
| Backup tidak lengkap | Database ada, folder upload tidak ikut | Daftar tertulis apa saja yang wajib dibackup |
| Dump database rusak atau kosong | File berukuran sangat kecil, restore error | Cek ukuran dan isi dump setiap job, uji restore rutin |
| Kunci enkripsi atau password arsip hilang | Arsip tidak bisa dibuka | Simpan kunci di password manager tim, terpisah dari server |
| Versi perangkat lunak tidak cocok | Dump dari versi baru gagal di versi lama | Catat versi PHP, database, dan aplikasi bersama backup |
| Backup ikut terhapus atau terenkripsi | Folder backup kosong setelah insiden | Salinan offline atau immutable di luar lokasi |
| Backup berhenti diam-diam | Backup terakhir ternyata berminggu-minggu lalu | Peringatan bila job gagal atau tidak berjalan |
| Hanya satu orang yang tahu caranya | Pemulihan menunggu orang itu bisa dihubungi | Dokumentasi langkah pemulihan yang bisa diikuti orang lain |
Dua penyebab terakhir paling mudah terlewat. Backup yang berhenti diam-diam baru ketahuan saat dibutuhkan, jadi pasang pemantauan yang memberi tahu bila job tidak berjalan, bukan hanya bila gagal. Dokumentasi pemulihan sebaiknya dijalankan oleh orang selain penulisnya. Di situlah langkah yang "dianggap semua orang sudah tahu" ketahuan tidak tertulis.
Dokumentasikan setiap latihan
Catatan latihan tidak perlu rumit. Satu dokumen per latihan cukup berisi: tanggal, sistem yang diuji, backup mana yang dipakai (tanggal dan lokasinya), siapa yang menjalankan, RPO dan RTO aktual dibandingkan target, masalah yang ditemukan, dan tindak lanjutnya.
Dari catatan itu kamu bisa melihat tren. Kalau RTO terus melebihi target, mungkin backup perlu disimpan lebih dekat, atau server cadangan perlu disiapkan lebih dulu. Kalau masalah yang sama muncul dua kali, berarti tindak lanjut sebelumnya belum benar-benar dikerjakan.
Seberapa sering harus diuji?
Tidak ada angka yang berlaku untuk semua bisnis. Sebagai titik awal yang masuk akal: pemeriksaan integritas otomatis setiap minggu, uji pemulihan sebagian (satu folder, satu database) setiap bulan, dan latihan pemulihan penuh beberapa kali setahun. Tambahkan latihan setiap kali ada perubahan besar, misalnya pindah server, ganti versi database, atau ganti alat backup.
Untuk membangun backup yang layak diuji sejak awal, mulai dari backup website otomatis dan prinsip aturan backup 3-2-1-1-0. Kalau kamu ingin tahu kenapa tim keamanan begitu menekankan hal ini, lihat pelajaran serangan ransomware PDN 2024.
Backup yang belum pernah dipulihkan masih berupa harapan. Jadwalkan latihan pertama bulan ini, cukup satu database, lalu biarkan catatan hasilnya menentukan apa yang diperbaiki berikutnya.
