Backup Restore Drill Database Produksi: Jangan Tunggu Bencana Baru Dites
Banyak tim merasa aman karena punya backup. Tetapi backup yang belum pernah direstore bukan jaminan. File backup bisa rusak, tidak lengkap, terlalu lama, tidak terenkripsi, atau ternyata tidak bisa dipakai saat insiden. Dalam produksi, yang penting bukan hanya punya backup, tetapi pernah membuktikan bahwa backup bisa memulihkan sistem.
Restore drill adalah latihan memulihkan database dari backup ke environment aman. Tujuannya bukan menunggu bencana, tetapi memastikan prosedur pemulihan benar-benar bekerja sebelum dibutuhkan.
Kenapa backup saja tidak cukup?
Backup adalah salinan data. Restore adalah kemampuan mengembalikan layanan. Banyak kegagalan baru terlihat saat restore: versi database berbeda, collation tidak cocok, user permission hilang, file terlalu besar, dump tidak konsisten, atau backup tidak mencakup tabel penting.
Jika bisnis bergantung pada saldo, order, deposit, session, atau audit log, backup yang gagal direstore bisa menjadi kerugian serius.
RPO dan RTO
RPO adalah seberapa banyak data yang sanggup hilang. Jika backup harian, kamu berisiko kehilangan data sejak backup terakhir. RTO adalah berapa lama sistem boleh down sampai pulih. Bisnis kecil sering tidak menuliskan dua angka ini, padahal keduanya menentukan strategi backup.
Contoh: jika RPO maksimal 15 menit, backup harian tidak cukup. Kamu perlu binlog, replication, atau backup incremental. Jika RTO maksimal 30 menit, restore manual tanpa latihan mungkin terlalu lambat.
Jenis backup
Full dump
Full dump mudah dipahami dan cocok untuk aplikasi kecil hingga menengah. Kekurangannya, proses bisa berat dan restore bisa lambat jika database besar.
Snapshot
Snapshot storage cepat, tetapi harus dipastikan konsisten. Untuk database aktif, snapshot tanpa koordinasi bisa menghasilkan data yang tidak aman.
Incremental dan binlog
Incremental backup dan binary log membantu recovery ke titik waktu tertentu. Ini lebih kompleks, tetapi penting untuk sistem yang tidak boleh kehilangan banyak transaksi.
Backup harus diamankan
Backup berisi data sensitif. Simpan dengan permission ketat, enkripsi jika memungkinkan, dan jangan letakkan di folder publik web. Batasi siapa yang bisa mengunduh backup. Jika backup dikirim ke storage eksternal, gunakan koneksi aman dan lifecycle policy.
Restore drill yang benar
- Buat environment restore yang terpisah dari production.
- Ambil backup terbaru.
- Restore ke database baru, bukan menimpa production.
- Jalankan migration compatibility check jika perlu.
- Hitung jumlah tabel dan row penting.
- Cek sample data transaksi.
- Jalankan smoke test aplikasi terhadap database restore.
- Catat waktu restore dari awal sampai siap dipakai.
Drill harus menghasilkan catatan: backup mana yang dipakai, durasi restore, error yang muncul, data apa yang diverifikasi, dan siapa yang menjalankan.
Validasi setelah restore
Jangan hanya melihat proses restore selesai. Cek tabel utama, jumlah row, index, foreign key, collation, user, view, trigger, dan scheduled job jika ada. Untuk aplikasi transaksi, cek beberapa order, balance log, deposit, dan data user secara sampling.
Kesalahan umum
- Backup tersimpan di server yang sama tanpa copy eksternal.
- Tidak pernah mencoba restore.
- Backup tidak terenkripsi.
- Backup mencakup database tetapi tidak mencakup file upload penting.
- Tidak ada dokumentasi langkah restore.
- Hanya satu orang yang tahu prosedur.
Frekuensi drill
Untuk aplikasi kecil, restore drill bulanan atau per kuartal sudah jauh lebih baik daripada tidak pernah. Untuk sistem yang menangani transaksi aktif, lakukan lebih sering dan otomatisasi sebagian validasinya. Drill juga perlu dilakukan setelah perubahan besar pada schema database.
Runbook restore
Runbook harus berisi lokasi backup, cara mengambil file, command restore, cara membuat database sementara, cara mengganti konfigurasi aplikasi jika perlu, smoke test, dan kontak yang harus diberi tahu. Runbook yang baik bisa diikuti engineer lain, bukan hanya orang yang membuat sistem.
Backup sebelum perubahan besar
Sebelum migration, perubahan worker, atau perbaikan data produksi, ambil backup fokus pada tabel terkait. Untuk operasi berisiko, backup bukan formalitas. Ia adalah jalan pulang jika perubahan tidak sesuai rencana.
FAQ
Apakah mysqldump cukup?
Untuk database kecil sampai menengah, bisa cukup jika konsisten, terjadwal, tersimpan aman, dan pernah diuji restore. Untuk volume besar atau RPO ketat, perlu strategi tambahan.
Apakah backup di server yang sama aman?
Tidak cukup. Jika server rusak atau terkena insiden, backup ikut hilang. Simpan salinan eksternal.
Apakah restore drill berbahaya?
Aman jika dilakukan di environment terpisah dan tidak menimpa production. Jangan melakukan drill dengan operasi tulis ke database live.
Kesimpulan
Backup bukan tujuan akhir. Tujuan akhirnya adalah recovery. Tim yang serius dengan produksi harus tahu seberapa cepat bisa memulihkan database, data apa yang mungkin hilang, dan langkah apa yang harus dilakukan saat insiden. Restore drill mengubah backup dari asumsi menjadi bukti.