Zálohování a disaster recovery pro databázi o desítkách TB

Question

IT Interview Practice · Accepted Answer

**Kombinujte periodické snapshoty s kontinuální WAL archivací pro point-in-time recovery, replikujte offsite/cross-region a dokažte to pravidelnými restore drilly proti explicitním cílům RPO/RTO.** Záloha, kterou jste nikdy neobnovili, je naděje, ne plán.

## Architektura

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

## Jak to funguje

- **Snapshoty** jsou plná kopie volume/clusteru (např. denní EBS snapshot nebo `pg_basebackup`). Jsou základem, ze kterého obnovujete — ale obnovení jen do včerejší noci ztratí den zápisů.
- **WAL / binlog archivace** streamuje každou změnu od posledního snapshotu do object storu kontinuálně. Obnovení = snapshot + přehrání WAL až do zvolené sekundy. To je **PITR (point-in-time recovery)** — obnovte na 10:32:04, okamžik před špatným `DELETE`.
- **Offsite / cross-region.** Záloha ve stejném regionu jako DB zemře s regionem. Replikujte do druhého regionu (S3 cross-region replication), aby regionální výpadek nebo ransomware nezasáhl obě.
- **Restore drilly.** Periodicky obnovujte do scratch prostředí, měřte, jak dlouho to trvalo (**RTO**) a kolik dat byste ztratili (**RPO**), a udělejte checksum proti produkci.

## RPO vs RTO

- **RPO (Recovery Point Objective)** = kolik dat si můžete dovolit ztratit. WAL archivace každých 5 min → RPO ≈ 5 min. Synchronní replika → RPO ≈ 0.
- **RTO (Recovery Time Objective)** = jak rychle musíte být zpět. Obnovení 20 TB z S3 může trvat hodiny; warm standby replika sníží RTO na minuty.

## Pohled z pohovoru

Tazatel zkoumá, zda víte, že **samotné snapshoty nestačí** (ztráta dat mezi nimi), zda umíte **definovat RPO/RTO v číslech** a zda **testujete obnovení**. Skvělé odpovědi zdůrazní, že netestované zálohy selžou přesně tehdy, když je potřebujete, a volí strategii z *byznysového* RPO/RTO, ne z pohodlí. Past: předpokládat, že read replika je záloha — replikace věrně zkopíruje i `DROP TABLE`.

## Kompromisy a selhání

- **Náklady vs RTO.** Warm cross-region standby dá minuty RTO, ale zdvojnásobí náklady na infra; cold S3 restore je levný, ale pomalý. Kupte vrstvu, kterou byznys skutečně potřebuje.
- **Zátěž zálohování.** Snapshotování hot 20TB DB přidá I/O; snapshotujte z repliky.
- **Tichá koruce.** WAL může archivovat poškozenou stránku; periodický full-restore + checksum ji zachytí.
- **Retence a compliance.** Držte dost historie (např. 35 dní PITR + měsíční archivy) pro legální potřeby; Glacier pro levné dlouhodobé.
- **Kdy ne:** malinká DB si vystačí s nočním `pg_dump` do S3 — plný WAL + cross-region standby je overkill, dokud ztráta dat není měřena v reálných penězích.

Architektura

Jak to funguje

RPO vs RTO

Pohled z pohovoru

Kompromisy a selhání

Související otázky