Backup og disaster recovery for en database på titalls TB

Question

IT Interview Practice · Accepted Answer

**Kombiner periodiske snapshots med kontinuerlig WAL-arkivering for point-in-time recovery, replikér offsite/cross-region, og bevis det med regelmessige restore-øvelser mot eksplisitte RPO/RTO-mål.** En backup du aldri har restaurert er et håp, ikke en plan.

## Arkitektur

```text
Primary DB ──snapshot (daglig)──▶ Object store (S3) ──cross-region replikering──▶ DR-region
     │                               ▲
     └── WAL/binlog stream ──────────┘   (kontinuerlig, PITR til hvilket som helst sekund)
                                          │
                          restore-øvelse ─┴──▶ verifisert restore ─▶ mål RTO, checksum RPO
```

## Slik fungerer det

- **Snapshots** er en full kopi av volumet/klusteret (f.eks. daglig EBS snapshot eller `pg_basebackup`). De er basen du restaurerer *fra* — men å restaurere kun til i går natt mister en dag med writes.
- **WAL / binlog-arkivering** streamer hver endring siden siste snapshot til object store kontinuerlig. Restore = snapshot + replay WAL opp til hvilket som helst valgt sekund. Dette er **PITR (point-in-time recovery)** — gjenopprett til 10:32:04, øyeblikket før en dårlig `DELETE`.
- **Offsite / cross-region.** En backup i samme region som DB-en dør med regionen. Replikér til en andre region (S3 cross-region replikering) slik at et regionalt utfall eller ransomware ikke tar begge.
- **Restore-øvelser.** Restaurer periodisk inn i et scratch-miljø, mål hvor lang tid det tok (**RTO**) og hvor mye data du ville ha mistet (**RPO**), og checksum mot prod.

## RPO vs RTO

- **RPO (Recovery Point Objective)** = hvor mye data du har råd til å miste. WAL-arkivering hvert 5. min → RPO ≈ 5 min. Synkron replica → RPO ≈ 0.
- **RTO (Recovery Time Objective)** = hvor raskt du må være tilbake. Å restaurere 20TB fra S3 kan ta timer; en warm standby replica kutter RTO til minutter.

## Intervjuperspektiv

Intervjueren undersøker om du vet at **snapshots alene ikke er nok** (datatap mellom dem), om du kan **definere RPO/RTO i tall**, og om du **tester restores**. Utmerkede svar understreker at utestede backups feiler akkurat når de trengs, og velger en strategi ut fra *forretningens* RPO/RTO, ikke fra bekvemmelighet. En felle: å anta at en read replica er en backup — replikering kopierer trofast en `DROP TABLE` også.

## Avveininger og feil

- **Kostnad vs RTO.** En warm cross-region standby gir minutter av RTO men dobler infra-kostnad; cold S3-restore er billig men treg. Kjøp laget forretningen faktisk trenger.
- **Backup-belastning.** Å snapshotte en hot 20TB DB legger til I/O; ta snapshots fra en replica.
- **Silent corruption.** WAL kan arkivere en korrupt page; periodisk full-restore + checksum fanger det.
- **Retention og compliance.** Behold nok historikk (f.eks. 35 dager PITR + månedlige arkiver) for juridiske behov; Glacier for billig langtidslagring.
- **Når ikke:** en bittelliten DB klarer seg fint med nattlig `pg_dump` til S3 — full WAL + cross-region standby er overkill til datatap måles i reelle penger.

Arkitektur

Slik fungerer det

RPO vs RTO

Intervjuperspektiv

Avveininger og feil

Relaterte spørsmål