Backup & disaster recovery voor een database van tientallen TB

Question

IT Interview Practice · Accepted Answer

**Combineer periodieke snapshots met continue WAL-archivering voor point-in-time recovery, repliceer offsite/cross-region, en bewijs het met regelmatige restore-oefeningen tegen expliciete RPO/RTO-doelen.** Een backup die je nooit hebt teruggezet is een hoop, geen plan.

## Architectuur

```text
Primaire DB ──snapshot (dagelijks)──▶ Object store (S3) ──cross-region replicatie──▶ DR-regio
     │                               ▲
     └── WAL/binlog-stream ──────────┘   (continu, PITR naar elke seconde)
                                          │
                        restore-oefening ─┴──▶ geverifieerde restore ─▶ meet RTO, checksum RPO
```

## Hoe het werkt

- **Snapshots** zijn een volledige kopie van het volume/cluster (bijv. dagelijkse EBS-snapshot of `pg_basebackup`). Ze zijn de basis waar je *van* restoret — maar alleen terugzetten naar gisteravond verliest een dag aan writes.
- **WAL / binlog-archivering** streamt continu elke wijziging sinds de laatste snapshot naar de object store. Restore = snapshot + WAL replayen tot elke gekozen seconde. Dit is **PITR (point-in-time recovery)** — herstel naar 10:32:04, het moment vóór een foute `DELETE`.
- **Offsite / cross-region.** Een backup in dezelfde regio als de DB sterft mee met de regio. Repliceer naar een tweede regio (S3 cross-region replicatie) zodat een regionale storing of ransomware niet beide meeneemt.
- **Restore-oefeningen.** Restore periodiek in een scratch-omgeving, meet hoe lang het duurde (**RTO**) en hoeveel data je zou hebben verloren (**RPO**), en checksum tegen prod.

## RPO versus RTO

- **RPO (Recovery Point Objective)** = hoeveel data je je kunt veroorloven te verliezen. WAL-archivering elke 5 min → RPO ≈ 5 min. Synchrone replica → RPO ≈ 0.
- **RTO (Recovery Time Objective)** = hoe snel je terug moet zijn. 20TB restoren uit S3 kan uren duren; een warm standby-replica knipt RTO terug naar minuten.

## Interviewperspectief

De interviewer peilt of je weet dat **snapshots alleen niet genoeg zijn** (dataverlies ertussen), of je **RPO/RTO in cijfers kunt definiëren**, en of je **restores test**. Uitstekende antwoorden benadrukken dat ongeteste backups falen precies wanneer je ze nodig hebt, en kiezen een strategie uit de *zakelijke* RPO/RTO, niet uit gemak. Een valkuil: aannemen dat een read replica een backup is — replicatie kopieert een `DROP TABLE` trouw mee.

## Afwegingen & faalmodi

- **Kosten versus RTO.** Een warme cross-region standby geeft minuten RTO maar verdubbelt infra-kosten; cold S3-restore is goedkoop maar traag. Koop de tier die de business echt nodig heeft.
- **Backup-belasting.** Een hot 20TB DB snapshotten voegt I/O toe; maak snapshots vanaf een replica.
- **Stille corruptie.** WAL kan een corrupte page archiveren; periodieke full-restore + checksum vangt het.
- **Retentie & compliance.** Bewaar genoeg historie (bijv. 35 dagen PITR + maandelijkse archieven) voor juridische behoeften; Glacier voor goedkope langetermijn.
- **Wanneer niet:** een kleine DB is prima met nachtelijke `pg_dump` naar S3 — volledige WAL + cross-region standby is overkill tot dataverlies in echt geld wordt gemeten.

Architectuur

Hoe het werkt

RPO versus RTO

Interviewperspectief

Afwegingen & faalmodi

Gerelateerde vragen