Belajar Vitess - Disaster Recovery & Business Continuity

#Pendahuluan

Episode 14 membahas desain DR multi-region. Episode 20 masuk ke level praktik: bagaimana memastikan rencana itu benar-benar bekerja saat dipanggil. Bencana bukan "jika", melainkan "kapan" — dan satu-satunya cara memastikan recovery berfungsi adalah mengujinya secara rutin, sebelum bencana sungguhan terjadi.

Roadmap episode 20: strategi backup penuh dan parsial, recovery drills, data integrity checks, lalu penanganan region outage dengan failover rehearsal.

#Strategi Backup Penuh dan Parsial

Backup adalah bahan mentah recovery. Strategi yang sehat menggabungkan beberapa jenis:

Backup penuh (full): snapshot seluruh data. Jarang, karena mahal — biasanya harian atau mingguan.
Backup inkremental: hanya perubahan sejak backup terakhir. Sering, murah, tapi recovery-nya lebih rumit.
Log shipping / replikasi: salinan berkelanjutan (replica atau binlog) untuk RPO mendekati nol.

Menjadwalkan backup berkala

vtctlclient Backup <tablet-alias-rdonly>

vtctlclient Backup memicu backup dari tablet RDONLY. Untuk otomatisasi, jadwalkan lewat cron atau Kubernetes CronJob. Aturan cadangan: backup harus dari RDONLY, disimpan ke lokasi yang terpisah dari cluster, dan diverifikasi.

Info

Kombinasi yang ideal: backup penuh mingguan, backup inkremental harian, plus replikasi lintas region untuk RPO rendah. Tiga lapis ini membuat kehilangan data dihitung dalam detik, bukan jam atau hari.

Strategi retensi juga penting: simpan beberapa siklus backup penuh untuk melindungi dari korupsi data yang baru terdeteksi berminggu-minggu kemudian. Backup yang terlalu cepat dihapus membuat kalian tidak bisa mundur ke titik sebelum data rusak.

#Recovery Drills

Recovery drill adalah ujian sebenarnya dari strategi backup. Aturan emasnya: backup yang tidak pernah diuji tidak bisa dipercaya. Latihan yang rutin meliputi:

Bangun cluster baru dari backup (restore penuh).
Verifikasi data bisa diquery.
Ukur waktu restore — apakah dalam target RTO?
Catat hambatan dan perbaiki runbook.

Restore dari backup saat bootstrap tablet

vtctlclient RestoreFromBackup <tablet-alias>

vtctlclient RestoreFromBackup mengembalikan tablet dari backup terbaru — proses yang sama saat tablet baru dibuat. Uji perintah ini di lingkungan terpisah secara rutin, bukan hanya saat darurat.

Warning

Jangan pernah menguji restore di cluster produksi dengan cara yang bisa merusak data. Gunakan cluster terpisah atau environment staging untuk drill. Tujuan drill adalah membuktikan proses, bukan menambah risiko.

#Data Integrity Checks

Setelah restore, data harus divalidasi — restore yang berhasil secara teknis tidak berarti data benar. Cara memeriksa integritas:

Checksum atau hash pada data penting, dibandingkan dengan nilai yang diharapkan.
Counts tabel: jumlah baris harus konsisten antar sumber dan target.
Query sampling: jalankan query bisnis yang diketahui hasilnya.
CHECK TABLE MySQL untuk integritas struktural.

Memeriksa integritas tabel

CHECK TABLE users

CHECK TABLE users memeriksa integritas tabel di MySQL. Untuk data yang lebih penting, kombinasikan dengan validasi aplikasi: jalankan test yang membandingkan hasil query sebelum dan sesudah restore.

#Menangani Region Outage

Ketika sebuah region benar-benar jatuh, kalian butuh urutan tindakan yang sudah disiapkan, bukan improvisasi. Urutan umumnya:

Deteksi dan konfirmasi — pastikan region benar-benar mati, bukan sekadar network hiccup.
Penilaian dampak — data apa yang terdampak, berapa traffic, berapa lama.
Eksekusi failover — promosi primary dari region cadangan (episode 14).
Pemulihan bertahap — kembalikan layanan, pantau beban.
Insiden review — catat apa yang terjadi dan perbaiki proses.

Menilai dampak saat outage

vtctlclient ListAllTablets -cell <region-bermasalah>
vtctlclient ListShardHealth -cell <region-cadangan>

vtctlclient ListShardHealth di region cadangan memberi gambaran apakah ada data yang siap dijadikan primary. Ini langkah kedua sebelum keputusan failover.

#Failover Rehearsal

Failover rehearsal adalah versi terjadwal dari drill: mensimulasikan kegagalan region dan menjalankan seluruh prosedur failover. Bedanya dengan recovery drill, rehearsal fokus pada proses operasional — siapa melakukan apa, kapan, dan lewat kanal apa.

Checklist rehearsal:

Runbook failover lengkap dan ter-update.
Personel yang bertanggung jawab teridentifikasi dan tersedia.
Komunikasi insiden teruji (siapa di-notify, bagaimana).
Metrik pemulihan tercatat untuk perbandingan.
Temuan dari rehearsal lalu lintas ke perbaikan runbook.

Success

Drill yang menemukan masalah bukan kegagalan — justru kesuksesan. Semakin banyak masalah ditemukan saat rehearsal, semakin sedikit yang mengejutkan saat bencana sungguhan. Tim yang paling tenang saat insiden adalah tim yang paling sering berlatih.

#Penutup

Pada episode 20 ini kalian sudah menyiapkan diri untuk skenario terburuk: strategi backup penuh dan parsial dengan retensi yang wajar, recovery drills yang rutin membuktikan backup bisa di-restore, data integrity checks setelah restore, penanganan region outage dengan urutan tindakan, dan failover rehearsal yang menempa runbook.

Inti yang harus dibawa pulang:

Kombinasikan backup penuh, inkremental, dan replikasi untuk RPO rendah.
Backup yang tidak pernah diuji restore-nya tidak bisa dipercaya.
Restore harus selalu diikuti validasi integritas data.
Region outage butuh urutan tindakan terencana, bukan improvisasi.
Failover rehearsal menempa runbook dan menenangkan tim saat insiden nyata.
Temuan drill adalah perbaikan proses, bukan kegagalan.

Di episode 21 berikutnya kita ukur dan jaga janji: observability at scale dan SLOs — mendefinisikan SLO untuk latensi, availability, dan throughput, memantau shard health, serta alerting pada replication lag, primary failure, dan query errors. Sampai jumpa!