Backup & disaster recovery ga database na tens of TB

Question

IT Interview Practice · Accepted Answer

**Haɗa periodic snapshots da continuous WAL archiving don point-in-time recovery, replicate offsite/cross-region, kuma ka tabbatar da shi da regular restore drills a kan bayyanannun RPO/RTO targets.** Backup da ba ka taɓa restore ba fata ne, ba shiri ba.

## Gine-gine

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

## Yadda yake aiki

- **Snapshots** cikakken kwafi ne na volume/cluster (misali daily EBS snapshot ko `pg_basebackup`). Su ne tushen da kake restore *daga* — amma restore zuwa jiya da dare kawai yana rasa writes na yini ɗaya.
- **WAL / binlog archiving** yana stream kowane canji tun snapshot na ƙarshe zuwa object store continuously. Restore = snapshot + replay WAL har zuwa kowace daƙiƙa da aka zaɓa. Wannan shi ne **PITR (point-in-time recovery)** — dawo zuwa 10:32:04, lokacin kafin `DELETE` mara kyau.
- **Offsite / cross-region.** Backup a yanki ɗaya da DB yana mutuwa da yanki. Replicate zuwa yanki na biyu (S3 cross-region replication) domin regional outage ko ransomware kada ya ɗauki dukan biyu.
- **Restore drills.** Lokaci-lokaci restore zuwa scratch environment, auna tsawon lokacin da ya ɗauka (**RTO**) da yawan data da za ka rasa (**RPO**), kuma ka checksum a kan prod.

## RPO vs RTO

- **RPO (Recovery Point Objective)** = yawan data da za ka iya rasa. WAL archiving kowane 5 min → RPO ≈ 5 min. Synchronous replica → RPO ≈ 0.
- **RTO (Recovery Time Objective)** = yadda za ka dawo da sauri. Restore na 20TB daga S3 na iya ɗaukar sa'o'i; warm standby replica yana rage RTO zuwa mintuna.

## Ra'ayin hira

Mai yin hirar yana bincike ko ka san **snapshots kaɗai ba su isa ba** (data loss tsakaninsu), ko za ka iya **bayyana RPO/RTO da lambobi**, kuma ko kana **gwada restores**. Amsoshi masu kyau sosai suna nuna cewa untested backups suna gazawa daidai lokacin da ake buƙata, kuma suna zaɓar strategy daga *business* RPO/RTO, ba daga saukin ba. Tarko: ɗaukar read replica a matsayin backup — replication yana kwafin `DROP TABLE` da aminci ma.

## Sulhu & kurakurai

- **Cost vs RTO.** Warm cross-region standby yana ba da mintuna na RTO amma yana ninka infra cost; cold S3 restore mai arha ne amma mai jinkiri. Sayi tier da business ke buƙata da gaske.
- **Backup load.** Snapshotting hot 20TB DB yana ƙara I/O; ɗauki snapshots daga replica.
- **Silent corruption.** WAL na iya archive corrupt page; periodic full-restore + checksum yana kama shi.
- **Retention & compliance.** Ajiye isashen history (misali 35 days PITR + monthly archives) don buƙatun doka; Glacier don long-term mai arha.
- **Lokacin da ba za a yi ba:** ƙaramin DB yayi kyau da nightly `pg_dump` zuwa S3 — full WAL + cross-region standby wuce gona da iri ne har data loss ya zama ainihin kuɗi.

Gine-gine

Yadda yake aiki

RPO vs RTO

Ra'ayin hira

Sulhu & kurakurai

Tambayoyi masu alaƙa