Backup & disaster recovery för en databas på tiotals TB

Question

IT Interview Practice · Accepted Answer

**Kombinera periodiska snapshots med kontinuerlig WAL-arkivering för point-in-time recovery, replikera offsite/cross-region, och bevisa det med regelbundna restore-övningar mot explicita RPO/RTO-mål.** En backup du aldrig har återställt är ett hopp, inte en plan.

## Arkitektur

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

## Så här fungerar det

- **Snapshots** är en full kopia av volymen/klustret (t.ex. daglig EBS-snapshot eller `pg_basebackup`). De är basen du återställer *från* — men att bara återställa till igår kväll förlorar en dags skrivningar.
- **WAL / binlog-arkivering** strömmar varje ändring sedan senaste snapshot till objektlagringen kontinuerligt. Restore = snapshot + replay WAL upp till valfri vald sekund. Detta är **PITR (point-in-time recovery)** — återhämta till 10:32:04, ögonblicket före en dålig `DELETE`.
- **Offsite / cross-region.** En backup i samma region som DB:n dör med regionen. Replikera till en andra region (S3 cross-region replication) så att ett regionalt avbrott eller ransomware inte tar båda.
- **Restore-övningar.** Återställ periodiskt till en scratch-miljö, mät hur lång tid det tog (**RTO**) och hur mycket data du skulle ha förlorat (**RPO**), och checksumma mot prod.

## RPO vs RTO

- **RPO (Recovery Point Objective)** = hur mycket data du har råd att förlora. WAL-arkivering var 5:e min → RPO ≈ 5 min. Synkron replica → RPO ≈ 0.
- **RTO (Recovery Time Objective)** = hur snabbt du måste vara tillbaka. Att återställa 20TB från S3 kan ta timmar; en warm standby-replica sänker RTO till minuter.

## Intervjuperspektiv

Intervjuaren undersöker om du vet att **snapshots ensamma inte räcker** (dataförlust mellan dem), om du kan **definiera RPO/RTO i siffror**, och om du **testar restores**. Utmärkta svar betonar att otestade backups fallerar precis när de behövs, och väljer en strategi från *affärens* RPO/RTO, inte från bekvämlighet. En fälla: att anta att en read replica är en backup — replikering kopierar troget ett `DROP TABLE` också.

## Avvägningar & fel

- **Kostnad vs RTO.** En warm cross-region standby ger minuter av RTO men fördubblar infra-kostnad; kall S3-restore är billig men långsam. Köp den nivå affären faktiskt behöver.
- **Backup-last.** Att snapshotta en het 20TB-DB lägger till I/O; ta snapshots från en replica.
- **Tyst korruption.** WAL kan arkivera en korrupt sida; periodisk full-restore + checksum fångar det.
- **Retention & efterlevnad.** Behåll tillräckligt med historik (t.ex. 35 dagars PITR + månatliga arkiv) för legala behov; Glacier för billig långtidslagring.
- **När inte:** en pytteliten DB klarar sig med nattlig `pg_dump` till S3 — full WAL + cross-region standby är överkill tills dataförlust mäts i verkliga pengar.

Arkitektur

Så här fungerar det

RPO vs RTO

Intervjuperspektiv

Avvägningar & fel

Relaterade frågor