Backup & pemulihan bencana untuk database berpuluh TB

Question

IT Interview Practice · Accepted Answer

**Gabungkan snapshot berkala dengan pengarkiban WAL berterusan untuk point-in-time recovery, replikasi luar tapak/rentas wilayah, dan buktikan dengan latihan restore berkala terhadap sasaran RPO/RTO yang eksplisit.** Sebuah backup yang tidak pernah anda restore ialah harapan, bukan rancangan.

## Seni bina

```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 ia berfungsi

- **Snapshot** ialah salinan penuh volum/cluster (cth. snapshot EBS harian atau `pg_basebackup`). Ia asas yang anda restore *daripadanya* — tetapi restore hanya ke malam tadi kehilangan sehari penulisan.
- **Pengarkiban WAL / binlog** mengalirkan setiap perubahan sejak snapshot terakhir ke object store secara berterusan. Restore = snapshot + replay WAL sehingga mana-mana saat yang dipilih. Ini ialah **PITR (point-in-time recovery)** — pulih ke 10:32:04, saat sebelum `DELETE` yang buruk.
- **Luar tapak / rentas wilayah.** Sebuah backup dalam wilayah yang sama dengan DB mati bersama wilayah itu. Replikasi ke wilayah kedua (S3 cross-region replication) supaya gangguan wilayah atau ransomware tidak mengambil kedua-duanya.
- **Latihan restore.** Secara berkala restore ke persekitaran calar (scratch), ukur berapa lama ia mengambil masa (**RTO**) dan berapa banyak data yang akan hilang (**RPO**), dan checksum terhadap prod.

## RPO vs RTO

- **RPO (Recovery Point Objective)** = berapa banyak data yang anda mampu hilang. Pengarkiban WAL setiap 5 min → RPO ≈ 5 min. Replica segerak → RPO ≈ 0.
- **RTO (Recovery Time Objective)** = berapa cepat anda mesti kembali. Restore 20TB dari S3 boleh mengambil masa berjam-jam; sebuah warm standby replica memotong RTO kepada beberapa minit.

## Perspektif temu duga

Penemu duga menyiasat sama ada anda tahu **snapshot sahaja tidak mencukupi** (kehilangan data antaranya), sama ada anda boleh **mentakrifkan RPO/RTO dalam nombor**, dan sama ada anda **menguji restore**. Jawapan yang hebat menekankan bahawa backup yang tidak diuji gagal tepat apabila diperlukan, dan memilih strategi daripada RPO/RTO *perniagaan*, bukan daripada kemudahan. Perangkap: menganggap sebuah read replica ialah backup — replication menyalin `DROP TABLE` dengan setia juga.

## Pertukaran & mod kegagalan

- **Kos vs RTO.** Sebuah warm cross-region standby memberi RTO beberapa minit tetapi menggandakan kos infra; restore cold S3 murah tetapi perlahan. Beli lapisan yang perniagaan sebenarnya perlukan.
- **Beban backup.** Snapshot DB 20TB panas menambah I/O; ambil snapshot dari sebuah replica.
- **Kerosakan senyap.** WAL boleh mengarkib halaman rosak; restore penuh berkala + checksum menangkapnya.
- **Retention & pematuhan.** Kekalkan cukup sejarah (cth. 35 hari PITR + arkib bulanan) untuk keperluan undang-undang; Glacier untuk jangka panjang murah.
- **Bila jangan:** sebuah DB kecil adalah baik dengan `pg_dump` malam ke S3 — WAL penuh + cross-region standby adalah berlebihan sehingga kehilangan data diukur dalam wang sebenar.

Seni bina

Cara ia berfungsi

RPO vs RTO

Perspektif temu duga

Pertukaran & mod kegagalan

Soalan berkaitan