Backup & disaster recovery for en database på titusinder af TB

Question

IT Interview Practice · Accepted Answer

**Kombinér periodiske snapshots med kontinuerlig WAL-arkivering til point-in-time recovery, replikér offsite/cross-region, og bevis det med regelmæssige restore-drills mod eksplicitte RPO/RTO-mål.** En backup du aldrig har restoret er et håb, ikke 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ådan virker det

- **Snapshots** er en fuld kopi af volume/cluster (fx daglig EBS-snapshot eller `pg_basebackup`). De er basen du restorer *fra* — men at restore kun til i nat mister en dags writes.
- **WAL / binlog-arkivering** streamer hver ændring siden sidste snapshot til object storen kontinuerligt. Restore = snapshot + replay WAL op til ethvert valgt sekund. Dette er **PITR (point-in-time recovery)** — genopret til 10:32:04, øjeblikket før et dårligt `DELETE`.
- **Offsite / cross-region.** En backup i samme region som DB'en dør med regionen. Replikér til en anden region (S3 cross-region replication) så et regionalt udfald eller ransomware ikke tager begge.
- **Restore-drills.** Restore periodisk ind i et scratch-miljø, mål hvor lang tid det tog (**RTO**) og hvor meget data du ville have mistet (**RPO**), og checksum mod prod.

## RPO vs RTO

- **RPO (Recovery Point Objective)** = hvor meget data du har råd til at miste. WAL-arkivering hvert 5. min → RPO ≈ 5 min. Synkron replica → RPO ≈ 0.
- **RTO (Recovery Time Objective)** = hvor hurtigt du skal være tilbage. At restore 20TB fra S3 kan tage timer; en warm standby-replica skærer RTO til minutter.

## Interview-perspektiv

Intervieweren undersøger, om du ved, at **snapshots alene ikke er nok** (datatab mellem dem), om du kan **definere RPO/RTO i tal**, og om du **tester restores**. Fremragende svar understreger, at utestede backups fejler præcis når der er brug for dem, og vælger en strategi ud fra *forretningens* RPO/RTO, ikke ud fra bekvemmelighed. En fælde: at antage, at en read replica er en backup — replikering kopierer trofast et `DROP TABLE` også.

## Trade-offs & fejl

- **Omkostning vs RTO.** En warm cross-region standby giver minutters RTO men fordobler infra-omkostning; cold S3-restore er billigt men langsomt. Køb den tier forretningen faktisk har brug for.
- **Backup-belastning.** At snapshotte en hot 20TB DB tilføjer I/O; tag snapshots fra en replica.
- **Silent korruption.** WAL kan arkivere en korrupt page; periodisk full-restore + checksum fanger det.
- **Retention & compliance.** Hold nok historik (fx 35 dages PITR + månedlige arkiver) til lovkrav; Glacier til billig langtidsopbevaring.
- **Hvornår ikke:** en lille DB klarer sig med natlig `pg_dump` til S3 — fuld WAL + cross-region standby er overkill, indtil datatab måles i reelle penge.

Arkitektur

Sådan virker det

RPO vs RTO

Interview-perspektiv

Trade-offs & fejl

Relaterede spørgsmål