Backup dan Disaster Recovery untuk Aplikasi Bisnis

Hampir semua perusahaan bilang sudah punya backup. Yang lebih sedikit adalah perusahaan yang bisa menjawab: berapa banyak data yang hilang kalau server database mati sekarang, berapa lama sampai aplikasi bisa berjalan lagi, dan kapan terakhir kali hal itu dibuktikan dengan restore. Pertanyaan-pertanyaan inilah yang penting saat insiden terjadi. Backup yang ada tapi belum pernah dicoba di-restore, disimpan di akun yang sama dengan production, atau butuh dua hari untuk dipulihkan tidak melindungi bisnis seperti yang dibayangkan.

Mulai dari RPO dan RTO

Sepakati angka-angka ini dengan pemilik bisnis setiap aplikasi, karena angka inilah yang menentukan biayanya. Backup harian berarti RPO bisa sampai 24 jam. Kehilangan pesanan satu hari penuh jarang bisa diterima, jadi sistem transaksi biasanya butuh backup database yang berjalan terus-menerus. RTO satu jam berarti proses restore harus sudah dibuat script-nya dan dilatih, karena tidak ada yang bisa membangun ulang server dari ingatan dalam enam puluh menit di tengah krisis.

Ikuti Aturan 3-2-1

• Simpan minimal tiga salinan data penting: data production dan dua backup.
• Simpan di minimal dua jenis media atau layanan yang berbeda.
• Simpan minimal satu salinan di lokasi lain, misalnya region lain, akun cloud lain, atau provider lain.
• Banyak tim menambahkan satu salinan yang immutable atau offline sehingga tidak bisa diubah, dan nol error saat uji restore.

Backup Semua yang Dibutuhkan Aplikasi

Restore yang berhasil butuh lebih dari sekadar dump database. Tulis daftar semua yang dibutuhkan untuk menghidupkan aplikasi lagi: database, file upload di storage, konfigurasi dan environment variable, secret seperti API key, record DNS, sertifikat TLS, dan definisi infrastrukturnya. Kode aplikasi biasanya sudah aman di Git, tapi hasil build dan image container yang dipakai di production juga harus bisa dibuat ulang. Infrastruktur yang ditulis sebagai kode, dengan Terraform atau tool sejenis, membuat proses membangun ulang server jadi langkah yang bisa diulang, tidak lagi pekerjaan manual yang panjang.

Backup Database dan Point-in-Time Recovery

Dump logis seperti pg_dump atau mysqldump memang sederhana dan mudah dipindahkan, tapi restore database besar dari dump bisa makan waktu berjam-jam, dan semua data sejak dump terakhir hilang. Point-in-time recovery menggabungkan backup penuh berkala dengan aliran log transaksi yang terus-menerus, seperti WAL archiving di PostgreSQL atau binary log di MySQL. Hasilnya, Anda bisa restore ke titik waktu mana pun, misalnya satu menit sebelum ada yang tidak sengaja menjalankan perintah delete yang salah. Managed database seperti Amazon RDS sudah menyediakan backup otomatis dengan point-in-time recovery, dengan masa simpan yang bisa diatur. Simpan dump sebagai salinan tambahan yang mudah dipindahkan, dan pakai point-in-time recovery untuk memenuhi RPO.

Lindungi Backup dari Ransomware dan Kesalahan

• Simpan minimal satu salinan di akun atau project terpisah dengan kredensial berbeda, supaya penyerang yang menguasai production tidak bisa menghapus backup.
• Pakai storage immutable seperti S3 Object Lock atau vault lock, supaya backup tidak bisa dihapus atau diubah selama masa simpannya.
• Enkripsi backup, dan simpan kunci enkripsinya di tempat yang tetap bisa diakses saat restore di tengah insiden.
• Batasi siapa yang boleh menghapus backup atau mengubah masa simpannya, dan kirim notifikasi kalau itu terjadi.
• Simpan riwayat yang cukup panjang. Ransomware atau data yang rusak kadang baru ketahuan berminggu-minggu kemudian, jadi masa simpan tujuh hari mungkin tidak menjangkau salinan yang masih bersih.

Pilih Strategi Pemulihan

Kebanyakan aplikasi bisnis sudah cukup dengan backup and restore atau pilot light, ditambah infrastruktur yang ditulis sebagai kode. Setup multi-site masuk akal untuk sistem yang setiap menit downtime-nya sangat mahal, dan butuh tim yang sanggup mengelola kerumitannya.

Jadwalkan Uji Restore

1. 1Tulis runbook pemulihan berisi langkah, perintah, dan orang yang terlibat, lalu simpan di luar sistem yang dijelaskannya.
2. 2Restore database ke environment terpisah setiap bulan dan pastikan aplikasi bisa membacanya.
3. 3Catat berapa lama proses restore-nya dan bandingkan dengan RTO.
4. 4Satu atau dua kali setahun, lakukan latihan penuh: bangun ulang aplikasi di region lain dari backup dan kode infrastruktur.
5. 5Perbarui runbook setelah setiap latihan, berdasarkan langkah yang kurang atau lambat.

Pantau Backup-nya Juga

Backup bisa gagal tanpa suara: disk penuh, kredensial kedaluwarsa, atau script yang berhenti setelah ada perubahan server. Kirim notifikasi kalau job backup gagal, dan juga kalau backup yang ditunggu tidak muncul, dengan pengecekan heartbeat. Pantau juga ukuran backup. Backup yang ukurannya tiba-tiba mengecil bisa berarti job-nya hanya menyimpan sebagian data.

Ajukan satu pertanyaan di rapat operasional berikutnya: kapan terakhir kali kita restore data production, dan berapa lama prosesnya? Kalau tidak ada yang tahu, jadwalkan uji restore pertama sebelum menambah tool backup baru.