Backup & disaster recovery për një bazë të dhënash prej dhjetëra TB

Question

IT Interview Practice · Accepted Answer

**Kombinoni snapshots periodikë me WAL archiving të vazhdueshëm për point-in-time recovery, replikoni offsite/cross-region, dhe provojeni me restore drills të rregullta kundër objektivave eksplicitë RPO/RTO.** Një backup që nuk e keni restoruar kurrë është një shpresë, jo një plan.

## Arkitektura

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

## Si funksionon

- **Snapshots** janë një kopje e plotë e volumit/klasterit (p.sh. një EBS snapshot ditor ose `pg_basebackup`). Ata janë baza prej së cilës restoroni — por restorimi vetëm deri mbrëmë humbet një ditë shkrimesh.
- **WAL / binlog archiving** bën stream të çdo ndryshimi që nga snapshot-i i fundit te object store në mënyrë të vazhdueshme. Restore = snapshot + replay WAL deri në çdo sekondë të zgjedhur. Ky është **PITR (point-in-time recovery)** — rikuperoni te 10:32:04, momenti para një `DELETE` të keq.
- **Offsite / cross-region.** Një backup në të njëjtin rajon me DB vdes me rajonin. Replikoni te një rajon i dytë (S3 cross-region replication) që një ndërprerje rajonale ose ransomware të mos i marrë të dyja.
- **Restore drills.** Periodikisht restoroni në një mjedis scratch, matni sa kohë mori (**RTO**) dhe sa të dhëna do të kishit humbur (**RPO**), dhe bëni checksum kundër prod.

## RPO vs RTO

- **RPO (Recovery Point Objective)** = sa të dhëna mund të përballoni të humbni. WAL archiving çdo 5 min → RPO ≈ 5 min. Replica sinkron → RPO ≈ 0.
- **RTO (Recovery Time Objective)** = sa shpejt duhet të ktheheni. Restorimi i 20TB nga S3 mund të marrë orë; një warm standby replica e pret RTO-në në minuta.

## Këndvështrimi i intervistës

Intervistuesi heton nëse dini se **snapshots vetëm nuk mjaftojnë** (humbje të dhënash mes tyre), nëse mund të **përcaktoni RPO/RTO në numra**, dhe nëse **testoni restore**. Përgjigjet e shkëlqyera theksojnë se backup-et e patestuar dështojnë pikërisht kur nevojiten, dhe zgjedhin një strategji nga RPO/RTO i *biznesit*, jo nga komoditeti. Një kurth: supozimi se një read replica është një backup — replikimi kopjon besnikërisht edhe një `DROP TABLE`.

## Kompromiset & gabimet

- **Kosto vs RTO.** Një warm cross-region standby jep minuta RTO por dyfishon koston e infrastrukturës; cold S3 restore është i lirë por i ngadaltë. Blini tier-in që biznesi ka vërtet nevojë.
- **Ngarkesa e backup.** Snapshot-imi i një DB 20TB të nxehtë shton I/O; merrni snapshots nga një replica.
- **Korruptim i heshtur.** WAL mund të arkivojë një faqe të korruptuar; full-restore periodik + checksum e kap atë.
- **Retention & compliance.** Mbani histori të mjaftueshme (p.sh. 35 ditë PITR + arkiva mujore) për nevojat ligjore; Glacier për afatgjatë të lirë.
- **Kur jo:** një DB e vockël është në rregull me një `pg_dump` natën te S3 — full WAL + cross-region standby është tepër derisa humbja e të dhënave matet në para reale.

Arkitektura

Si funksionon

RPO vs RTO

Këndvështrimi i intervistës

Kompromiset & gabimet

Pyetje të ngjashme