Lakukan pemulihan, bukan sekadar berasumsi

Pertanyaan

Kalau data atau region hilang, berapa banyak yang hilang dan berapa lama sampai layanan pulih, dan bukti apa yang kita punya?

Setelah baca ini, kamu bisa menetapkan RPO dan RTO per data, menjelaskan kenapa replika bukan backup, dan merancang latihan restore yang menghasilkan angka nyata.

Prasyarat dan contoh

Kamu paham replikasi dan durabilitas (M01.04 dan modul penyimpanan), dan deploy yang aman di M16.03. Di sini fokusnya: pemulihan sebagai prosedur yang diuji, bukan fitur yang dianggap ada.

Contoh: sebuah tim punya database dengan dua replika di zona berbeda dan merasa "datanya aman". Suatu sore skrip pembersihan salah jalan dan DELETE tanpa WHERE menghapus tabel pesanan. Replika menyalin penghapusan itu dalam hitungan detik. Backup harian ada, tapi belum pernah dicoba dipulihkan, dan ternyata butuh 9 jam untuk 1,2 TB, padahal tim mengira satu jam.

Mekanisme

RPO (recovery point objective) adalah batas data yang boleh hilang, diukur dalam waktu: "maksimum 5 menit transaksi terakhir". RTO (recovery time objective) adalah batas lama layanan boleh nggak pulih: "layanan kembali dalam 60 menit". Keduanya ditetapkan per data atau per layanan, bukan satu angka buat semuanya. Pesanan butuh RPO menit, log analitik mungkin cukup RPO 24 jam.

Replika melindungi dari kegagalan mesin atau zona, bukan dari kesalahan logis. Replikasi menyalin perubahan, termasuk yang salah: penghapusan, bug aplikasi yang menulis data rusak, ransomware. Replika sinkron memberi RPO nol terhadap kehilangan node, tapi nggak ada gunanya terhadap DELETE yang keliru.

Backup adalah salinan pada titik waktu yang terpisah dari sistem sumber. Syaratnya:

• Terpisah. Akun, kredensial, dan jika bisa region berbeda. Backup yang bisa dihapus pakai kredensial yang sama dengan produksi akan ikut hilang saat kredensial bocor.
• Tak dapat diubah (immutable atau object lock) selama masa retensi.
• Punya retensi yang menjawab "kesalahan ketahuan berapa lama kemudian". Kalau korupsi ketahuan setelah 10 hari tapi retensi 7 hari, semua backup sudah berisi data rusak.

Point-in-time recovery (PITR) menggabungkan backup penuh dengan log tulis berkelanjutan (WAL/binlog), sehingga bisa memulihkan ke menit tertentu, mis. 14:07 sebelum DELETE terjadi. RPO ditentukan oleh seberapa sering log diarsipkan, misalnya tiap 1 menit atau saat segmen penuh.

RTO ditentukan oleh waktu restore, bukan keberadaan backup. Perkiraan kasar: 1,2 TB dengan throughput efektif 150 MB/detik butuh 1.200.000 MB / 150 = 8.000 detik, sekitar 2,2 jam, belum termasuk replay log, pembangunan ulang indeks, pemanasan cache, dan verifikasi. Hanya latihan yang memberi angka sebenarnya.

Latihan restore itu prosedur berulang: pulihkan ke lingkungan terpisah, jalankan pemeriksaan integritas (jumlah baris, checksum, query bisnis kunci), catat waktu tiap langkah, dan bandingkan dengan RPO/RTO. Jadwalkan berkala (mis. bulanan, plus tiap perubahan besar pada infrastruktur) dan otomatiskan sebanyak mungkin.

Saat rancangan ini gagal

• Replika dianggap backup. Kesalahan logis menyebar ke semua salinan.
• Backup di akun dan kredensial yang sama. Penyerang atau skrip yang salah menghapus produksi dan backup sekaligus.
• RTO dihitung dari ukuran data saja. Restore, replay, indeks, dan cache dingin bisa melipatgandakan waktu.
• Kunci enkripsi ikut hilang. Backup terenkripsi tanpa salinan kunci terpisah adalah data yang nggak bisa dibaca.
• Retensi terlalu pendek. Kesalahan yang ketahuan terlambat sudah menimpa semua titik pulih.
• Hanya database yang dipulihkan. Object storage, konfigurasi, secret, dan antrean ikut menentukan apakah layanan benar-benar hidup. Konsistensi antar-penyimpanan juga bisa rusak setelah restore pada titik waktu berbeda.
• Pemulihan lintas region tanpa kapasitas. Failover ke region cadangan yang nggak punya kapasitas atau data terbaru cuma memindahkan masalah.

Contoh tandingan: untuk data yang bisa dibangun ulang dari sumber (cache, indeks pencarian), backup kadang lebih mahal dan lambat daripada membangun ulang. RPO/RTO-nya diwujudkan lewat rebuild yang diuji, bukan backup.

Latihan

Database pesanan 800 GB. Target: RPO 5 menit, RTO 2 jam. Kondisi sekarang: replika sinkron di dua zona, snapshot penuh harian, arsip WAL tiap 15 menit, retensi 3 hari. Throughput restore terukur 100 MB/detik. Replay WAL sehari rata-rata 25 menit.

1. Apakah RPO terpenuhi? Apa yang kamu ubah?
2. Estimasi RTO untuk pemulihan terburuk (WAL sehari penuh). Terpenuhi?
3. Sebutkan dua kerentanan tambahan dan satu latihan yang kamu jadwalkan.

Lihat pembahasan+

1. Belum. Arsip WAL tiap 15 menit berarti data terakhir hingga 15 menit bisa hilang kalau server dan replika hilang bersamaan (misalnya penghapusan logis plus restore). Turunkan interval arsip ke 1 menit (atau streaming WAL ke penyimpanan terpisah) supaya RPO sekitar 1 sampai 5 menit.
2. Salin snapshot: 800 GB = 800.000 MB / 100 = 8.000 detik, sekitar 133 menit. Tambah replay WAL 25 menit dan verifikasi, totalnya sekitar 2,5 jam lebih, jadi RTO 2 jam nggak terpenuhi. Opsi: snapshot lebih sering (mis. 6 jam sekali) supaya replay pendek, restore paralel, atau standby yang selalu hangat bila RTO benar-benar harus 2 jam.
3. Kerentanan: retensi 3 hari terlalu pendek buat kesalahan yang baru ketahuan setelah akhir pekan, dan backup belum tentu terpisah akun serta immutable. Latihan: restore bulanan ke lingkungan terpisah dengan PITR ke satu menit tertentu, ukur waktu tiap langkah, verifikasi jumlah baris dan total nilai pesanan, lalu bandingkan dengan RTO 2 jam.

Menetapkan angka tanpa latihan hanya menggeser asumsi ke angka.

Terkait

• M01.04 Pasang target yang masuk akal membedakan durabilitas dari ketersediaan.
• M16.03 Deploy dan migrasikan dengan aman membahas batas rollback, titik di mana backup jadi jalan keluar.
• M16.06 Tangani insiden dan tinjau rancangan memakai hasil latihan ini sebagai input respons insiden.

Catatan

• Asumsi: throughput restore konstan dan sumber data tunggal. Praktiknya bervariasi menurut jaringan, disk, dan beban lain.
• Angka retensi, interval arsip, dan jadwal latihan adalah contoh, bukan rekomendasi universal.
• Yang nggak dibahas: pemulihan multi-region aktif-aktif, prosedur hukum untuk retensi data, dan produk backup spesifik vendor.
• Terakhir ditinjau: 26 Oktober 2026.