Biztonsági mentés és disaster recovery egy több tíz TB-os adatbázishoz

Question

IT Interview Practice · Accepted Answer

**Kombináld a periodikus snapshotokat folyamatos WAL archiválással a point-in-time recoveryhez, replikálj offsite/cross-region, és bizonyítsd rendszeres restore drillekkel explicit RPO/RTO célok ellen.** Egy backup, amit sosem állítottál vissza, egy remény, nem egy terv.

## Architektúra

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

## Hogyan működik

- **A snapshotok** a kötet/fürt teljes másolatai (pl. napi EBS snapshot vagy `pg_basebackup`). Ezek az alap, amiből *visszaállítasz* — de a csak tegnap estig való visszaállítás egy nap írásait elveszíti.
- **WAL / binlog archiválás** az utolsó snapshot óta minden változást folyamatosan az object store-ba streamel. Restore = snapshot + WAL replay bármely választott másodpercig. Ez a **PITR (point-in-time recovery)** — visszaállítás 10:32:04-re, a rossz `DELETE` előtti pillanatra.
- **Offsite / cross-region.** Egy backup a DB-vel azonos régióban a régióval együtt hal meg. Replikálj egy második régióba (S3 cross-region replikáció), hogy egy regionális kiesés vagy ransomware ne vigye el mindkettőt.
- **Restore drillek.** Periodikusan állíts vissza egy scratch környezetbe, mérd meg mennyi ideig tartott (**RTO**) és mennyi adatot vesztettél volna (**RPO**), és checksumolj a prod ellen.

## RPO vs RTO

- **RPO (Recovery Point Objective)** = mennyi adatot engedhetsz meg elveszíteni. WAL archiválás 5 percenként → RPO ≈ 5 perc. Szinkron replika → RPO ≈ 0.
- **RTO (Recovery Time Objective)** = milyen gyorsan kell visszatérned. 20TB visszaállítása S3-ból órákba telhet; egy meleg standby replika percekre csökkenti az RTO-t.

## Interjú szemszög

Az interjúztató azt vizsgálja, tudod-e, hogy a **snapshotok önmagukban nem elegek** (adatvesztés köztük), tudod-e **számokban definiálni az RPO/RTO-t**, és **teszteled-e a restore-okat**. A kiváló válaszok hangsúlyozzák, hogy a nem tesztelt backupok pontosan akkor hibáznak, amikor szükség van rájuk, és az *üzleti* RPO/RTO-ból választanak stratégiát, nem kényelemből. Csapda: azt feltételezni, hogy egy read replika egy backup — a replikáció egy `DROP TABLE`-t is hűségesen lemásol.

## Kompromisszumok és hibák

- **Költség vs RTO.** Egy meleg cross-region standby perces RTO-t ad de duplázza az infra költséget; a hideg S3 restore olcsó de lassú. Vedd meg azt a réteget, amire az üzletnek valóban szüksége van.
- **Backup terhelés.** Egy forró 20TB-os DB snapshotolása I/O-t ad; készíts snapshotokat egy replikáról.
- **Csendes korrupció.** A WAL egy korrupt lapot is archiválhat; a periodikus teljes restore + checksum elkapja.
- **Retention és megfelelőség.** Tarts elég történelmet (pl. 35 nap PITR + havi archívumok) a jogi igényekhez; Glacier az olcsó hosszú távúhoz.
- **Mikor ne:** egy apró DB rendben van egy éjszakai `pg_dump`-pal S3-ba — a teljes WAL + cross-region standby túlzás, amíg az adatvesztés valós pénzben mérhető.

Architektúra

Hogyan működik

RPO vs RTO

Interjú szemszög

Kompromisszumok és hibák

Kapcsolódó kérdések