Backup & Disaster Recovery für eine Datenbank von zig TB

Question

IT Interview Practice · Accepted Answer

**Kombiniere periodische Snapshots mit kontinuierlichem WAL-Archiving für Point-in-time Recovery, repliziere offsite/cross-region und beweise es mit regelmäßigen Restore-Drills gegen explizite RPO-/RTO-Ziele.** Ein Backup, das du nie wiederhergestellt hast, ist eine Hoffnung, kein Plan.

## Architektur

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

## Wie es funktioniert

- **Snapshots** sind eine vollständige Kopie des Volumes/Clusters (z. B. täglicher EBS-Snapshot oder `pg_basebackup`). Sie sind die Basis, *von der* du wiederherstellst - aber nur auf letzte Nacht wiederherzustellen verliert einen Tag an Writes.
- **WAL-/Binlog-Archiving** streamt jede Änderung seit dem letzten Snapshot kontinuierlich in den Object Store. Restore = Snapshot + WAL-Replay bis zu einer beliebig gewählten Sekunde. Das ist **PITR (Point-in-time Recovery)** - Wiederherstellung auf 10:32:04, den Moment vor einem falschen `DELETE`.
- **Offsite / Cross-Region.** Ein Backup in derselben Region wie die DB stirbt mit der Region. Repliziere in eine zweite Region (S3 Cross-Region Replication), sodass ein regionaler Ausfall oder Ransomware nicht beide erwischt.
- **Restore-Drills.** Stelle periodisch in eine Scratch-Umgebung wieder her, miss, wie lange es dauerte (**RTO**) und wie viele Daten du verloren hättest (**RPO**), und prüfe per Checksumme gegen Prod.

## RPO vs. RTO

- **RPO (Recovery Point Objective)** = wie viele Daten du dir leisten kannst zu verlieren. WAL-Archiving alle 5 Min → RPO ≈ 5 Min. Synchrone Replica → RPO ≈ 0.
- **RTO (Recovery Time Objective)** = wie schnell du zurück sein musst. 20TB aus S3 wiederherzustellen kann Stunden dauern; ein Warm Standby Replica senkt die RTO auf Minuten.

## Interview-Perspektive

Der Interviewer sondiert, ob du weißt, dass **Snapshots allein nicht genügen** (Datenverlust dazwischen), ob du **RPO/RTO in Zahlen definieren** kannst und ob du **Restores testest**. Hervorragende Antworten betonen, dass ungetestete Backups genau dann scheitern, wenn sie gebraucht werden, und wählen eine Strategie aus dem *Business*-RPO/RTO, nicht aus Bequemlichkeit. Eine Falle: anzunehmen, eine Read Replica sei ein Backup - Replikation kopiert ein `DROP TABLE` getreulich mit.

## Trade-offs & Fehler

- **Kosten vs. RTO.** Ein Warm Cross-Region Standby gibt Minuten an RTO, verdoppelt aber die Infra-Kosten; ein Cold-S3-Restore ist günstig, aber langsam. Kaufe die Stufe, die das Business tatsächlich braucht.
- **Backup-Last.** Eine heiße 20TB-DB zu snapshotten fügt I/O hinzu; nimm Snapshots von einer Replica.
- **Stille Korruption.** WAL kann eine korrupte Page archivieren; periodischer Full-Restore + Checksumme fängt das.
- **Retention & Compliance.** Halte genug Historie (z. B. 35 Tage PITR + monatliche Archive) für rechtliche Anforderungen; Glacier für günstige Langzeit.
- **Wann nicht:** eine winzige DB ist mit nächtlichem `pg_dump` nach S3 in Ordnung - volles WAL + Cross-Region Standby ist Overkill, bis Datenverlust in echtem Geld gemessen wird.

Architektur

Wie es funktioniert

RPO vs. RTO

Interview-Perspektive

Trade-offs & Fehler

Ähnliche Fragen