Backup & disaster recovery untuk database berukuran puluhan TB

Question

IT Interview Practice · Accepted Answer

**Kombinasikan snapshot berkala dengan WAL archiving berkelanjutan untuk point-in-time recovery, replikasi ke luar lokasi/lintas-region, dan buktikan dengan restore drill rutin terhadap target RPO/RTO eksplisit.** Sebuah backup yang tidak pernah Anda restore adalah harapan, bukan rencana.

## Arsitektur

```text
Primary DB ──snapshot (daily)──▶ Object store (S3) ──cross-region replicate──▶ DR region
     │                               ▲
     └── WAL/binlog stream ──────────┘   (continuous, PITR to any second)
                                          │
                          restore drill ──┴──▶ verified restore ─▶ measure RTO, checksum RPO
```

## Cara kerjanya

- **Snapshot** adalah salinan penuh volume/cluster (mis. EBS snapshot harian atau `pg_basebackup`). Itu adalah basis yang Anda restore *dari*-nya — tetapi restore hanya ke semalam kehilangan sehari write.
- **WAL / binlog archiving** men-stream setiap perubahan sejak snapshot terakhir ke object store secara berkelanjutan. Restore = snapshot + replay WAL hingga detik yang dipilih. Ini **PITR (point-in-time recovery)** — pulih ke 10:32:04, momen sebelum `DELETE` yang buruk.
- **Luar lokasi / lintas-region.** Backup di region yang sama dengan DB mati bersama region itu. Replikasi ke region kedua (S3 cross-region replication) agar padamnya region atau ransomware tidak melenyapkan keduanya.
- **Restore drill.** Restore secara berkala ke environment scratch, ukur berapa lama waktunya (**RTO**) dan berapa banyak data yang akan hilang (**RPO**), dan checksum terhadap prod.

## RPO vs RTO

- **RPO (Recovery Point Objective)** = seberapa banyak data yang Anda mampu kehilangan. WAL archiving setiap 5 menit → RPO ≈ 5 menit. Replica sinkron → RPO ≈ 0.
- **RTO (Recovery Time Objective)** = seberapa cepat Anda harus kembali. Me-restore 20TB dari S3 bisa memakan jam; sebuah warm standby replica memangkas RTO ke menit.

## Perspektif wawancara

Pewawancara menyelidiki apakah Anda tahu **snapshot saja tidak cukup** (kehilangan data di antaranya), apakah Anda bisa **mendefinisikan RPO/RTO dalam angka**, dan apakah Anda **menguji restore**. Jawaban hebat menekankan bahwa backup yang tak teruji gagal persis saat dibutuhkan, dan memilih strategi dari RPO/RTO *bisnis*, bukan dari kenyamanan. Jebakan: mengasumsikan read replica adalah backup — replikasi dengan setia menyalin `DROP TABLE` juga.

## Trade-off & kegagalan

- **Biaya vs RTO.** Warm cross-region standby memberi RTO menit tetapi menggandakan biaya infra; cold S3 restore murah tetapi lambat. Beli tier yang benar-benar dibutuhkan bisnis.
- **Beban backup.** Snapshot DB 20TB panas menambah I/O; ambil snapshot dari replica.
- **Korupsi senyap.** WAL bisa mengarsipkan page rusak; full-restore + checksum berkala menangkapnya.
- **Retensi & kepatuhan.** Simpan cukup histori (mis. 35 hari PITR + arsip bulanan) untuk kebutuhan legal; Glacier untuk jangka panjang murah.
- **Kapan tidak perlu:** DB mungil cukup dengan `pg_dump` malam hari ke S3 — full WAL + cross-region standby berlebihan sampai kehilangan data diukur dalam uang nyata.

Arsitektur

Cara kerjanya

RPO vs RTO

Perspektif wawancara

Trade-off & kegagalan

Pertanyaan terkait