DR-Strategien und RTO/RPO

1) Grundprinzipien

1. Ziele vor Mitteln. Zuerst formulieren wir RTO/RPO und kritische Szenarien, dann wählen wir die Technologie.
2. Segmentierung nach Wichtigkeit. Nicht alle Dienstleistungen erfordern „Gold“; Teilen Sie nach Geschäftskritik.
3. Daten sind der Kern von DR. Konsistenz, Replikation, Verderb-Erkennung und Wiederherstellungspunkt sind wichtiger als Hardware.
4. Automatisierung und Überprüfbarkeit. DR ist ohne IaC, Regress-Recovery-Tests und Telemetrie bedeutungslos.
5. Lehren und Beweise. Ein Plan ohne regelmäßigen „Spieltag“ ist die Illusion der Bereitschaft.
6. Sicherheit und Compliance. Verschlüsselung, Isolation, WORM/immutable-Backups, DPA/Jurisdiktionen.

2) Begriffe und Entsprechungen

RTO - Die Zeit vom Zeitpunkt des Ereignisses bis zur Wiederherstellung des Dienstes ist „normal“.
RPO ist das „Alter“ des letzten gesunden Datenpunkts bei der Wiederherstellung.
RLO (Recovery Level Objective) - Das Niveau der Funktionalität, das wiederhergestellt werden muss (Minimum Viable Service).
MTD (Maximum Tolerable Downtime) ist die Schwelle, ab der ein Unternehmen einen inakzeptablen Schaden erleidet.
RTA/RPA (Actual) - Tatsächliche Zeit/Wiederherstellungspunkt aus der Praxis.

Kommunikation: RTO ≤ MTD; RPA ≤ RPO. Die Kluft zwischen Zielen und Fakten ist Gegenstand von Postmortem und Verbesserungen.

3) DR-Strategieklassen (Bereitschaftsstufen)

4) Szenarien, gegen die wir uns wehren

Verlust der Region/Cloud/Rechenzentrum (Elektrik, Netz, Anbieter).
Datenkorruption/Bedienerfehler (Löschen, „zerbrochene“ Replikate, logische Beschädigung).
Malware/Ransomware.
Release/Konfigurationsfehler (Massen-Outage).
Zusammenbruch der Abhängigkeit (KMS, DNS, Geheimnisse, Zahlungsanbieter).
Rechtliche Ereignisse (Sperren, Verbot der Entfernung von Daten aus der Gerichtsbarkeit).

Geben Sie für jedes Szenario RTO/RPO, DR-Level, Playbook und Verantwortliche an.

5) Datenstrategien (Schlüssel zu RPO)

5. 1 Backups

Vollständige + inkrementelle + Transaktionslogs (für DB).
Immutable/WORM-Speicher und Offline-Kopien („air-gapped“).
Verzeichnis der Backups mit Metadaten und Krypto-Signaturen; Testwiederherstellung nach Zeitplan.

5. 2 Replikation

Synchron (niedriger RPO, ↑latentnost, Risiko der Ausbreitung von Verderb).
Asynchron (geringe Auswirkung auf Perf, RPO> 0; Kombination mit dem Verderb).
CDC (Change Data Capture) für Streaming-Replikation und Statusrekonstruktion.

5. 3 Schutz vor logischem Verderb

Versionierung/“ Point-in-Time“ (PITR) mit einem Fenster ≥ N Tage.
Signaturen von Invarianten (Salden, Summen, Chexummas) sind ein frühes Detail von „gebrochenen“ Daten.
„Langsame“ Replikationskanäle (Verzögerung 15-60 min) als Puffer gegen sofortigen Verderb.

python def pick_restore_point(pitr, anomaly_signals, max_age):
healthy = [p for p in pitr if not anomaly_signals. after(p. time)]
return max(healthy, key=lambda p: p. time if now()-p. time <= max_age else -1)

6) Anwendung, Status, Cache

Statless Layer - Skalieren und neu starten in jeder Region (Bild/Diagramme/Manifeste in Git).
Zustand (DB/Caches/Q): Die Quelle der Wahrheit ist eine der DBs; Caches und Indizes sind neu generierbar.
Idempotenz und Re-Drive - wiederholte Lieferung von Ereignissen ist zulässig; Verwenden Sie outbox/inbox, dedup und Versionen.

7) Netzwerk und Eingangspunkt

GSLB/DNS-Failover: Latenz/gesundheitsbasiert, kurze TTL im Unfallfenster.
Anycast/L7-Proxy: einheitliche IP, Routing für die Gesundheit der Regionen.
Regionale Domänen und Rechtsprechungsrichtlinien (Geo-Pinning für PII).
Zertifikat-Failover/KMS: Ersatzketten, Dual-Key.

python if slo_breach("region-a") or health("region-a")==down:
route. shift(traffic, from_="region-a", to="region-b", step=20) # канарим enable_readonly_if_needed()

8) Betriebsmodell und Automatisierung

IaC/GitOps: Infrastruktur der zweiten Region = Code, Ein-Knopf-Bereitstellung.
Policy as Code: Gate „keine DR-Manifeste/Backups/Alert - keine Freigabe“.
Runbooks: Schritt-für-Schritt-Anleitung und „roter Knopf“, identisch zu beiden Regionen.
Geheimnisse: kurzlebige Credits, OIDC Federation, Kompromittierungs-/Recall-Plan.

rego package dr deny["Missing PITR ≥ 7d"] {
input. db. pitr_window_days < 7
}
deny["No restore test in 30d"] {
now() - input. db. last_restore_test > 3024h
}

9) Übungen und Tests (Spieltage)

Szenariotabelle: DB-Verlust, „defekte“ Daten, KMS-Ausfall, Regionsturz, plötzliches Egress-Limit.
Häufigkeit: vierteljährlich für missionskritische; Alle sechs Monate für die anderen.
Übungsmetriken: RTA/RPA vs Ziele, Anteil automatischer Schritte, Anzahl manueller Eingriffe, Playbook-Fehler.
Chaos-Rauch in Releases: Der Abbau von Abhängigkeiten sollte DR-Pfade nicht „brechen“.

T0: cut off the primary database (firewall drop)
T + 2m: GSLB shift 20% of traffic, then 100% at SLO_ok
T + 6m: checking business invariants and lag replication
T + 10m: post-drill: fixing RTA/RPA, playbook improvements

10) Playbooks (kanonische Vorlage)

yaml playbook: "dr-failover-region-a-to-b"
owner: "platform-sre"
rto: "15m"
rpo: "5m"
triggers:
- "health(region-a)==down"
- "slo_breach(payments)"
prechecks:
- "backup_catalog ok; last_restore_test < 30d"
- "pitr_window >= 7d"
steps:
- "Announce incident; open war-room; assign IC"
- "Freeze writes in region-a (flag write_readonly)"
- "Promote db-b to primary; verify replication stopped cleanly"
- "Shift GSLB 20%→50%→100%; monitor p95/error"
- "Enable compensations and re-drive queues"
validation:
- "Business invariants (balances, duplicate_checks)"
- "Synthetic tests green; dashboards stable 30m"
rollback:
- "If db-b unhealthy: revert traffic; engage restore from PITR T-Δ"
comms:
- "Status updates each 15m; external note if SEV1"

11) Beobachtungsmetriken DR

Replica lag (Sek.), RPO-drift (Differenz zwischen Soll und Ist-RPO).
Restore SLI: Zeit der kalten/warmen Erholung in der Umgebung.
Coverage:% der Dienste mit Playbooks/Backups/PITR ≥ N Tagen.
Drill score: Anteil der automatischen Schritte, RTA-Verteilung, Fehlerrate.
Immutability:% der Backups in WORM/air-gapped.
Ereignismetriken: Länge der Warteschlangen/Geschwindigkeit des Re-Drive nach dem Failover.

12) Kosten und Kompromisse

CapEx/OpEx: Warmer Stand billiger als Active/Active, aber teurer als Pilot Light.
Egress: Interregionale/Inter-Cloud-Replikation kostet Geld; Cache/Kompression/lokale Aggregate.
RTO/RPO vs $: Jede „Neun“ der Verfügbarkeit und eine Sekunde RPO kosten ein Vielfaches mehr - stimmen Sie mit dem Geschäft überein.
Grüne Fenster: Batch-Replikation - in billigen/„ grünen “Uhren.

13) Sicherheit und Compliance

Verschlüsselung "in Ruhe" und "im Transit', getrennte KMS-Domänen nach Regionen.
Immutable-Backups, Schutz vor Ransomware: „3-2-1“ (3 Kopien, 2 Medien, 1 offline), MFA-delete.
Gerichtsbarkeiten: Geo-Pinning für PII, Lokalisierung von Backups, Legal Hold über TTL.
Zugriffe nach Zeit: temporäre Rollen für DR-Operationen, Audit-Log.

14) Anti-Muster

„Wir schreiben später einen Plan“ - DR ohne Übung.
Replikation ohne Schutz vor logischem Verderb - multipliziert den Fehler blitzartig.
Eine Region KMS/Geheimnisse - kein Failover möglich.
Backups ohne regelmäßige Genesene - die „Schrödinger“ DR.
Eng verwandte synchrone Transaktionen zwischen Regionen - kaskadierende Latenz/Drop.
Keine Priorisierung: gleiche DR-Ebene für alles (teuer und nutzlos).

15) Checkliste des Architekten

1. RTO/RPO/RLO nach Service und Szenario definiert?
2. Klassifizierte Daten: Quelle der Wahrheit, PITR/Fenster, WORM/immutable?
3. DR-Level (Backup/Restore, Pilot, Warm, A/P, A/A) per Service ausgewählt?
4. Netzwerk: GSLB/Anycast, Zertifikate/Schlüssel mit Bestand, „nur lesen“ Flags?
5. Anhang: Idempotenz, Outbox/Inbox, kompensierende Transaktionen?
6. IaC/GitOps/Policy as Code: Ein Klick auf das Roll-out der zweiten Region?
7. Übung: Zeitplan, RTA/RPA KPI, Post-Training-Aktionen?
8. Überwachung: lag, RPO-drift, restore-SLI, drill-score, immutable backups?
9. Sicherheit/Compliance: KMS-Domains, Jurisdiktionen, Legal Hold?
10. Kosten: egress Budget, „grüne“ Fenster, wirtschaftlich vertretbares Niveau?

16) Mini-Rezepte und Skizzen

16. 1 PITR für Postgres (Idee):

bash base backup daily + WAL archive pg_basebackup -D/backups/base/$ (date +% F)
archive_command='aws s3 cp %p s3://bucket/wal/%f --sse'
restore pg_restore --time "2025-10-31 13:21:00Z"...

16. 2 Schutz vor logischem Verderb (verzögerte Replik):

yaml replication:
mode: async apply_delay: "30m" # window to roll back on corruption

16. 3 Verkehrsumschaltung (GSLB Pseudo-API):

bash gslb set-weight api. example. com region-a 0 gslb set-weight api. example. com region-b 100

16. 4 Prüfung der Invarianten nach dem Failover (Pseudocode):

python assert total_balance(all_accounts) == snapshot_total assert no_duplicates(events_since(t_failover))

Schlussfolgerung

DR ist die Fähigkeit, technische und organisatorische Entscheidungen schneller zu treffen, als der Schaden wächst. Identifizieren Sie realistische RTOs/RPOs, wählen Sie eine ausreichende Bereitschaftsstufe, automatisieren Sie Infrastruktur und Inspektionen, trainieren Sie regelmäßig und messen Sie die tatsächlichen RTAs/RPAs. Dann wird aus dem Unfall kein Desaster, sondern ein überschaubarer Vorfall mit absehbarem Ausgang.