Disaster recovery (DR) menyatukan semua bab sebelumnya menjadi satu kemampuan organisasi: pulih dari kondisi terburuk dalam waktu dan kerusakan yang masih bisa diterima. Pertanyaannya bergeser dari “bagaimana cara backup” menjadi “ketika hal buruk terjadi, siapa melakukan apa, dengan alat apa, dan berapa lama”. Chapter ini memetakan empat skenario bencana beserta RTO dan RPO masing-masing, memisahkan peran replica set dari peran backup, lalu menutup dengan runbook sederhana dan pola komunikasi tim yang bisa langsung diadopsi.
Peta materi Chapter ini:
- Empat skenario bencana dan jawaban teknisnya, dengan RTO/RPO per skenario.
- Mengapa failover replica set bukan pengganti backup.
- Runbook pemulihan lima langkah dan pola komunikasi tim saat insiden.
Empat Skenario Bencana #
Tidak semua bencana sama — dan keempat kategori ini menuntut jawaban yang berbeda:
| Skenario | Jawaban pertama | RTO tipikal | RPO tipikal |
|---|---|---|---|
| Satu node mati (hardware, maintenance) | Failover otomatis replica set | Detik hingga ±1 menit | 0 — data tetap utuh |
| Satu region/data center bermasalah | Promote node di region lain, atau restore snapshot ke region sehat | Jam | 0 bila multi-region; selisih oplog/snapshot bila tidak |
| Berkas data korup atau storage rusak | Initial sync ulang dari node sehat; bila menyebar, restore penuh | Jam | 0 dari node sehat; selisih backup bila restore |
| Kesalahan manusia (drop database, skrip salah) | Point-in-time recovery atau restore backup | Jam | Sebelum momen kesalahan (PITR) atau jarak backup |
Perhatikan baris terakhir — baris yang paling sering terjadi di dunia nyata. Failover tidak bisa menolong karena replica set menyalin semua tulisan, termasuk yang salah, ke seluruh node dalam hitungan detik.
Failover Bekerja di Lapisan Ketersediaan #
Saat seorang primary jatuh, replica set otomatis memilih primary baru di antara node yang tersisa — aplikasi hanya merasakan jeda singkat tanpa perlu campur tangan manual. Kesehatan topologi bisa kita periksa kapan saja; berikut kondisi replica set latihan kita:
rs.status().members.map(m => ({
name: m.name,
stateStr: m.stateStr,
health: m.health
}))Output yang Dihasilkan:
[ { name: '127.0.0.1:27017', stateStr: 'PRIMARY', health: 1 } ]Satu anggota, sehat, berstatus PRIMARY. Pada cluster produksi tiga anggota, daftar ini menampilkan ketiganya — dan saat satu jatuh, status anggota itu berubah tidak sehat sementara dua lainnya tetap melayani. Lapisan inilah yang membuat baris pertama tabel di atas ber-RTO hitungan detik: tidak ada proses restore yang perlu dijalankan.
Untuk skenario kesalahan manusia, kerjanya justru di lapisan data. Mari kita mainkan versi mininya — data penting terhapus, lalu dipulihkan dari backup:
use latihan_backup
db.dropDatabase()
db.penjualan.insertOne({ _id: 201, bukuId: 1, jumlah: 3 })
db.penjualan.deleteOne({ _id: 201 })
db.penjualan.find({ _id: 201 })
db.penjualan.insertOne({ _id: 201, bukuId: 1, jumlah: 3 })
db.penjualan.find({ _id: 201 })Output yang Dihasilkan:
switched to db latihan_backup
{ ok: 1, dropped: 'latihan_backup' }
{ acknowledged: true, insertedId: 201 }
{ acknowledged: true, deletedCount: 1 }
{ acknowledged: true, insertedId: 201 }
[ { _id: 201, bukuId: 1, jumlah: 3 } ]Cursor find yang tidak mencetak apa-apa setelah deleteOne adalah momen “data sudah tidak ada di mana pun” — replica set sebesar apa pun memberikan hasil yang sama, karena deleteOne tereplikasi ke seluruh anggota. Baris terakhir memperlihatkan keadaan setelah pemulihan: pada praktik sungguhan, dua baris insert itu digantikan prosedur PITR atau restore dari chapter sebelumnya, dan verifikasi find wajib menyertainya.
Runbook Pemulihan Lima Langkah #
Runbook adalah resep yang ditulis sebelum insiden, saat kepala masih dingin. Versi minimalnya:
| Langkah | Tindakan | Kriteria selesai |
|---|---|---|
| 1. Deklarasi | Umumkan insiden di satu channel, tunjuk satu pemimpin insiden | Semua pihak tahu channel tunggal dan pengambil keputusan |
| 2. Diagnosis | Tentukan skenario (node? region? korupsi? kesalahan manusia?) dan dampaknya | Skenario teridentifikasi, keputusan jalur pemulihan diambil |
| 3. Pemulihan | Jalankan prosedur: tunggu failover / promote / restore / PITR | Prosedur selesai tanpa galat |
| 4. Verifikasi | Checklist chapter Restore Testing: jumlah, query sampel, smoke test aplikasi | Seluruh checklist LULUS |
| 5. Penutupan | Umumkan pemulihan, catat kronologi, jadwalkan retro | Laporan insiden tertulis |
Dua detail kecil yang berdampak besar: catat waktu setiap keputusan (untuk retro dan evaluasi RTO aktual), dan jangan pernah melakukan restore langsung ke cluster produksi yang masih melayani trafik — pulihkan ke environment terpisah, verifikasi, baru alihkan.
Komunikasi Tim #
Sisi manusiawi DR justru yang paling sering gagal. Pola yang terbukti bekerja mengikuti prinsip satu sumber kebenaran: satu channel untuk seluruh komunikasi insiden, satu pemimpin insiden yang berkoordinasi (tidak harus orang paling teknis), dan pembaruan status terjadwal — misalnya setiap 30 menit — bahkan ketika kabarnya “masih menyelidiki”. Diam membuat ruang untuk spekulasi; kabar berkala, sekecil apa pun, menahannya.
Dua kebiasaan penutup: pertama, jalankan game day — latihan DR berkala di mana tim benar-benar menjalankan runbook pada environment uji, bukan sekadar membacanya; kedua, simpan runbook di lokasi yang bisa diakses tanpa sistem yang sedang bermasalah — runbook yang hanya ada di wiki internal cluster yang sedang down tidak bernilai.
Rangkuman #
- Empat skenario bencana menuntut jawaban berbeda: failover untuk node, promote lintas region untuk data center, initial sync untuk korupsi, dan PITR/restore untuk kesalahan manusia.
- Replication menjawab ketersediaan (RTO detik), backup menjawab integritas data — kesalahan tulisan tereplikasi secepat data benar, jadi keduanya wajib berpasangan.
- Runbook lima langkah: deklarasi, diagnosis, pemulihan, verifikasi, penutupan — dengan satu channel komunikasi, satu pemimpin insiden, dan pembaruan status terjadwal.
- Latih runbook lewat game day dan simpan di lokasi yang tetap dapat diakses saat sistem utama sedang bermasalah.