Belajar Database Administrator - Disaster Recovery & Business Continuity

#Pendahuluan

High availability (episode 8) melindungi dari kegagalan satu node. Tapi bagaimana kalau yang mati adalah satu region — listrik padam, gempa, atau gangguan cloud provider? Di sinilah Disaster Recovery (DR) dan Business Continuity (BC) masuk. HA menangani menit; DR menangani jam hingga hari, dan harus menjawab pertanyaan: berapa banyak data boleh hilang? berapa cepat bisnis harus pulih?

Dua angka ini adalah bahasa bisnis yang harus kalian kuasai. Sebelum kalian bisa mengajukan budget untuk replikasi lintas region, kalian harus bisa menjawab RPO dan RTO dengan percaya diri.

#RPO & RTO: Dua Angka Suci

• RPO (Recovery Point Objective): jumlah data maksimum yang boleh hilang — diukur mundur dalam waktu. RPO 15 menit = "kalau bencana terjadi, kita rela kehilangan data maksimal 15 menit terakhir".
• RTO (Recovery Time Objective): waktu maksimum layanan boleh mati — diukur maju dari bencana. RTO 4 jam = "dalam 4 jam setelah bencana, layanan harus sudah jalan lagi".

Keduanya bukan angka yang ditentukan DBA sendirian — mereka hasil negosiasi dengan bisnis: seberapa besar dampak finansial data hilang, dan seberapa cepat pelanggan tidak sabar. Tugas DBA menerjemahkannya menjadi arsitektur:

Aturan emas: semakin kecil RPO/RTO, semakin mahal. RPO 0 butuh dua region sinkron; RTO menit butuh mesin standby yang terus menyala. Realisme bisnis menentukan angka — dan kalian yang menyampaikan harga tiap pilihan.

#Replikasi Lintas Region

Untuk melindungi dari kegagalan region, data harus ada di lebih dari satu lokasi geografis. Tiga pendekatan:

1. Replikasi log-based antar region: PostgreSQL pg_basebackup + streaming ke region kedua; MySQL binlog replikasi lintas region. Sederhana, tapi failover manual.
2. Managed cross-region: RDS Cross-Region Read Replica, Aurora Global Database (replikasi ~1 detik), Cloud SQL cross-region. Provider mengelola mekanismenya.
3. Pitfall utama: latency & lag antar region — replikasi lintas benua selalu tertinggal detik; RPO 0 lintas region memerlukan solusi synchronous khusus yang jarang praktis untuk database besar.

aws rds create-db-instance-read-replica \
    --db-instance-identifier appdb-dr \
    --source-db-instance-identifier appdb \
    --region us-west-2 \
    --db-instance-class db.m5.large

Selalu pantau replay_lag/ReplicaLag lintas region sebagai metrik utama DR — masuk ke dashboard episode 7.

#Backup Off-Site: Jaring Pengaman Terakhir

Replikasi punya kelemahan: jika bencana adalah korupsi logika (misal query bug menghapus 100 ribu baris), replikasi dengan patuh menyalin kehancuran itu ke semua region. Satu-satunya pertahanan: backup off-site yang immutable.

Pola yang benar:

• Backup harian/periodik (episode 5) disinkronkan ke object storage lintas region.
• Backup tersebut immutable — tidak bisa dihapus/diubah bahkan oleh admin (WORM / object lock).
• Retensi jelas: harian 14 hari, mingguan 2 bulan, bulanan 1 tahun.

aws s3 sync /backup/ s3://backups-dr/appdb/ \
    --region ap-southeast-1 --delete
aws s3api put-object-lock-configuration \
    --bucket backups-dr \
    --object-lock-configuration '{"ObjectLockEnabled":"Enabled",...}'

Inilah jawaban untuk skenario terburuk: database dihapus oleh kesalahan, versi semua region ikut — tapi backup immutable tetap bisa di-restore.

#DR Drill Plan: Prosedur yang Diuji

Dokumen DR yang tidak pernah diuji hanyalah angan-angan. DR drill adalah latihan kebakaran: serangkaian langkah yang dijalankan berkala untuk membuktikan RTO/RPO tercapai.

Contoh runbook drill:

1. Skenario: hilangkan akses ke region primary (stop instance, blok jaringan).
2. Promosi: failover ke region kedua — managed (auto) atau manual (repmgr promote).
3. Restore terkini: jika menggunakan backup, restore + PITR.
4. Validasi: query sanity, hitung baris, cek koneksi aplikasi.
5. Ukur: catat waktu tempuh tiap langkah vs target RTO.
6. Post-mortem (gaya episode 20): apa yang gagal? perbaiki runbook.

[ ] Backup terakhir berhasil & teruji restore
[ ] Akses runbook tersedia (bahkan saat office offline)
[ ] Endpoint/DNS siap dialihkan
[ ] Kredensial DR tersimpan terpisah & aman
[ ] Semua yang on-call pernah menjalankan drill ini

#DR Architecture Roadmap

Bergantung ukuran organisasi, DR bertingkat:

1. Tier 1 (startup): backup harian off-site + restore manual. RTO 12-24 jam, RPO 24 jam. Murah, cukup untuk memulai.
2. Tier 2 (produksi): PITR + replicas + runbook + drill kuartal. RTO 1-4 jam, RPO 5-15 menit.
3. Tier 3 (kritis): cross-region replicas + managed global DB + automated failover. RTO menit, RPO detik. Mahal — hanya untuk yang benar-benar butuh.

Mulai dari tier yang sesuai, naikkan seiring nilai bisnis data. Dokumentasikan tiap tier, siapa yang berwenang memutuskan failover, dan bagaimana komunikasi ke pemangku kepentingan.

#Penutup

Inti yang harus dibawa pulang:

• RPO = data maksimal yang boleh hilang; RTO = waktu maksimal layanan mati — keduanya hasil negosiasi bisnis dan penerjemahan teknis.
• Replikasi lintas region melindungi dari kegagalan region; pantau replay_lag sebagai metrik DR.
• Backup off-site yang immutable adalah pertahanan terakhir dari korupsi logika — dan beda dengan replikasi.
• DR drill adalah latihan kebakaran: jalankan sungguhan, ukur waktu, perbaiki runbook — berkala.

Di episode 16 selanjutnya kita menghadapi hukum dan aturan: data governance & compliance — data masking, retention policy, audit trails, dan kepatuhan GDPR/PCI-DSS/UU PDP yang mengubah pekerjaan DBA dari teknis murni menjadi jembatan antara data dan kepatuhan. Sampai jumpa di episode 16!