Backup și disaster recovery pentru o bază de date de zeci de TB

Question

IT Interview Practice · Accepted Answer

**Combină snapshot-uri periodice cu arhivare continuă de WAL pentru point-in-time recovery, replică offsite/cross-region și dovedește-o cu drill-uri de restore regulate față de ținte RPO/RTO explicite.** Un backup pe care nu l-ai restaurat niciodată este o speranță, nu un plan.

## Arhitectură

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

## Cum funcționează

- **Snapshot-urile** sunt o copie completă a volumului/clusterului (de ex. snapshot EBS zilnic sau `pg_basebackup`). Sunt baza *de la care* restaurezi — dar restaurarea doar până aseară pierde o zi de scrieri.
- **Arhivarea WAL / binlog** transmite continuu fiecare modificare de la ultimul snapshot către object store. Restore = snapshot + replay WAL până la orice secundă aleasă. Aceasta este **PITR (point-in-time recovery)** — recuperezi la 10:32:04, momentul dinaintea unui `DELETE` greșit.
- **Offsite / cross-region.** Un backup în aceeași regiune ca DB-ul moare odată cu regiunea. Replică într-o a doua regiune (S3 cross-region replication), astfel încât o cădere regională sau un ransomware să nu le ia pe amândouă.
- **Drill-uri de restore.** Restaurează periodic într-un mediu de test, măsoară cât a durat (**RTO**) și câte date ai fi pierdut (**RPO**), și fă checksum față de producție.

## RPO vs RTO

- **RPO (Recovery Point Objective)** = câte date îți poți permite să pierzi. Arhivare WAL la fiecare 5 min → RPO ≈ 5 min. Replică sincronă → RPO ≈ 0.
- **RTO (Recovery Time Objective)** = cât de repede trebuie să fii înapoi. Restaurarea a 20TB din S3 poate dura ore; o replică warm standby taie RTO-ul la minute.

## Perspectiva de interviu

Intervievatorul sondează dacă știi că **snapshot-urile singure nu sunt suficiente** (pierdere de date între ele), dacă poți **defini RPO/RTO în cifre** și dacă **testezi restore-urile**. Răspunsurile excelente subliniază că backup-urile netestate eșuează exact când e nevoie și aleg o strategie din RPO/RTO-ul de *business*, nu din comoditate. O capcană: a presupune că o read replica este un backup — replicarea copiază fidel și un `DROP TABLE`.

## Compromisuri și eșecuri

- **Cost vs RTO.** Un warm cross-region standby dă minute de RTO, dar dublează costul de infrastructură; restore-ul cold din S3 este ieftin, dar lent. Cumpără tier-ul de care business-ul chiar are nevoie.
- **Încărcarea de backup.** Snapshot-area unui DB hot de 20TB adaugă I/O; ia snapshot-uri de pe o replică.
- **Corupție silențioasă.** WAL poate arhiva o pagină coruptă; full-restore periodic + checksum o prinde.
- **Retenție și conformitate.** Ține suficient istoric (de ex. 35 de zile PITR + arhive lunare) pentru nevoile legale; Glacier pentru long-term ieftin.
- **Când nu:** un DB minuscul este în regulă cu `pg_dump` nocturn către S3 — WAL complet + cross-region standby este exagerat până când pierderea de date se măsoară în bani reali.

Arhitectură

Cum funcționează

RPO vs RTO

Perspectiva de interviu

Compromisuri și eșecuri

Întrebări conexe