Backup & disaster recovery kanggo database puluhan TB

Question

IT Interview Practice · Accepted Answer

**Gabungake snapshot periodik karo arsip WAL terus-terusan kanggo point-in-time recovery, replikasi offsite/lintas-region, lan buktikake nganggo latihan restore rutin marang target RPO/RTO sing jelas.** Backup sing durung tau sampeyan restore iku pangarep-arep, dudu 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 kerjane

- **Snapshot** iku salinan lengkap volume/cluster (contone snapshot EBS saben dina utawa `pg_basebackup`). Iku dhasar sing sampeyan restore *saka* — nanging restore mung menyang mau bengi ilang sedina tulisan.
- **Arsip WAL / binlog** nge-stream saben owah-owahan wiwit snapshot pungkasan menyang object store terus-terusan. Restore = snapshot + replay WAL nganti detik sing dipilih. Iki **PITR (point-in-time recovery)** — pulih menyang 10:32:04, sadurunge `DELETE` sing ala.
- **Offsite / lintas-region.** Backup ing region sing padha karo DB mati bareng regione. Replikasi menyang region kapindho (S3 cross-region replication) supaya gangguan regional utawa ransomware ora njupuk loro-lorone.
- **Latihan restore.** Kanthi periodik restore menyang lingkungan scratch, ukur suwene (**RTO**) lan sepira data sing bakal ilang (**RPO**), lan checksum marang prod.

## RPO vs RTO

- **RPO (Recovery Point Objective)** = sepira data sing bisa sampeyan tanggung ilang. Arsip WAL saben 5 menit → RPO ≈ 5 menit. Replika sinkron → RPO ≈ 0.
- **RTO (Recovery Time Objective)** = sepira cepet sampeyan kudu bali. Restore 20TB saka S3 bisa butuh pirang-pirang jam; replika standby anget ngurangi RTO dadi pirang-pirang menit.

## Sudut pandang wawancara

Pewawancara nyoba niteni apa sampeyan ngerti yen **snapshot thok ora cukup** (data ilang ing antarane), apa sampeyan bisa **nemtokake RPO/RTO kanthi angka**, lan apa sampeyan **nguji restore**. Jawaban apik banget nandhesake yen backup sing ora diuji gagal pas nalika dibutuhake, lan milih strategi saka RPO/RTO *bisnis*, dudu saka kepénak. Jebakane: nganggep read replica minangka backup — replikasi kanthi setya nyalin `DROP TABLE` uga.

## Trade-off & kegagalan

- **Biaya vs RTO.** Standby lintas-region anget menehi RTO pirang-pirang menit nanging nggandakake biaya infra; restore S3 adhem murah nanging alon. Tuku tier sing pancen dibutuhake bisnis.
- **Beban backup.** Nge-snapshot DB 20TB sing panas nambah I/O; jupuk snapshot saka replika.
- **Korupsi sepi.** WAL bisa ngarsipake kaca sing rusak; full-restore periodik + checksum nangkep iku.
- **Retensi & kepatuhan.** Jaga sejarah sing cukup (contone 35 dina PITR + arsip saben wulan) kanggo kabutuhan hukum; Glacier kanggo jangka panjang murah.
- **Nalika ora usah:** DB cilik cukup nganggo `pg_dump` saben wengi menyang S3 — WAL lengkap + standby lintas-region iku keladuk nganti data ilang diukur nganggo dhuwit tenanan.

Arsitektur

Cara kerjane

RPO vs RTO

Sudut pandang wawancara

Trade-off & kegagalan

Pitakon sing gegandhengan