Disaster Recovery и cold-backups

Kurze Zusammenfassung

DR ist die Fähigkeit, die Funktionen eines Unternehmens nach einem schweren Unfall wiederherzustellen. Cold-backups sind die „letzte Verteidigungslinie“: unveränderliche/isolierte Kopien, die für die Wiederherstellung geeignet sind, wenn der Standort vollständig stromlos ist oder kompromittiert wird. Die Strategie basiert auf RTO/RPO, Systempriorisierung, jährlichen DR-Übungen und strenger Betriebsdisziplin (Kataloge, Schlüssel, Inspektionen).

Begriffe und Ziele

RPO (Recovery Point Objective) ist der maximal zulässige Datenverlust (z. B. ≤ 15 Minuten).
RTO (Recovery Time Objective) - die maximal zulässige Wiederherstellungszeit (z. B. ≤ 2 Stunden).
Black-start - Wiederherstellung „von Grund auf“: Hardware/Cluster/Geheimnisse/Daten/DNS.
Air-gap - Physische/logische Isolierung von Kopien (Band/deaktiviertes Konto/Offline-Medium).
Immutability (WORM) - unveränderliche Speicherung (Band/Objekt mit Lock/Retention).

DR-Bereitschaftsstufen

Cold Site - Infrastruktur fehlt/eingefroren; RTO: Stunden-Tage; billigste CAPEX/OPEX.
Warm Site - Vorlagen/Bilder/teilweise fertige Dienste; RTO: Dutzende Minuten-Stunden.
Hot Site - aktive Repliken; RTO: Minuten; teurer und komplizierter.
Hybrid: Kernel → hot/warm, alles andere → cold (mit Startpriorisierung).

Wo Cold-Backups unverzichtbar sind

Massive Kryptoverwertung/Domain-Kompromittierung.
Datenkorruption, die alle Repliken verlassen hat.
Verlust der Region/des Rechenzentrums, höhere Gewalt (Feuer, Überschwemmung).
Absichtliche Entfernung/Sabotage von privilegierten Konten.

Topologie von Cold-Backups

1. Medien/Speicherklassen

Bänder (LTO-8/9): billig, Standard-Air-Gap, hohe Kapazität, serieller Zugriff.
Offline-Laufwerke/NAS: „Safe-Cases“, nur im Backup/Restore-Fenster verbunden.
Archivierte Objektklassen (Glacier-like): niedriger Speicherpreis, höhere Abrufzeiten.

2. Unterbringung

Anderer Standort/Region; anderer Anbieter/Account; einzelne Schlüssel/Administratoren.

3. Immutabilität

WORM/Object Lock (Compliance/Governance) Bänder mit Retench und Legal Hold.

3-2-1-1-0-Richtlinie (mit Fokus auf Kälte)

3 Kopien der Daten (Prod + Local Backup + Offsite).
2 verschiedene Medien (Disc/Band/Objekt).
1 Offsite (anderer Standort/Cloud).
1 unveränderlich (WORM/air-gap).
0 Prüffehler (checksum/periodische Testwiederherstellung).

Verzeichnisse, Metadaten und Integritätsprüfung

Verzeichnis der Backups: was, wo, wann, Version, Schlüssel, Scheckbeträge, Laufzeit retenschna.
Asset-Verzeichnis: Dienst → Abhängigkeit → volume/baket → Priorität.
Checksums und manifest-Dateien: Abstimmung auf Aufzeichnung und auf Wiederherstellung.
Canary-Dateien: regelmäßige Wiederherstellung für die frühe Erkennung von Trägerproblemen.

Verschlüsselung und Schlüssel

Verschlüsselung im Ruhezustand (Band/Objekt) und im Flug (Kopieren).
KMS/Vault mit Dual-Control, Offline-Tresore für Master-Schlüssel, Rotation.
Separate Schlüssel für Prod/Backups/Archive (Minimierung des Blast-Radius).
Dokumentierter Schlüsselzugriffsprozess bei DR (Anforderungen, Rollen, Protokoll).

DR-Plan: Priorisierung und Konsistenz

1. Identifikation und Zugriff: IdP (minimale Zone), Vault/KMS, Netzwerkkern.

2. Daten und Kontrollebenen: etcd K8s, configs, secrets, Bilderregister, deploys Artefakte.

3. Transaktions-DB/Wallet: Protokolle + neueste voll/inkrementell.

4. Payment/Integration Gateways: Schlüssel, Zertifikate, IP/DNS.

5. Web/Upi-Fronten: Kanarienstart, statische Inhalte aus dem Objekt.

6. Analytik/Reporting: nach Fertigstellung des Kernels.

1. Infrastruktur: Netzwerk, DNS/Anycast, Kernel-IAM, Basis-Images/Cluster.

2. Geheimnisse/Zertifikate: Vault/KMS aus Cold-Backup wiederherstellen, Bootstrap-Geheimnisse verteilen.

3. Bezugsebene: etcd/Control Plane/Register/Repositories.

4. Daten: DB aus cold-backup + PITR aus Logs (per RPO) bereitstellen.

5. Anwendungen: Baumabhängigkeiten starten, Caches/CDNs aufwärmen.

6. Tests und Validierung: Gesundheitsproben, Konsistenz, Prüfsummen.

7. Verkehrsumschaltung: DNS/Routing/Balancer (etappenweise/kanarisch).

8. Post-Checks: keine Lecks/Schulden, Protokollierung und Akt DR.

Cold-Restore-Verfahren (typisch)

Bänder: Inventar, Download, parallele Streams, Map-Dateien → Verzeichnisse → Tasks für die Wiederherstellung; Berücksichtigung von Such- und Rückspulzeiten.
Archivklassen: Anforderung zur Extraktion (minutes→hours), Staging im Hot Storage, Wiederherstellung per Manifest.
Offline-Laufwerke: Read-only-Verbindung, Checksum-Prüfungen → Kopieren.
Praxis: isolierte „Sandbox“ für die Wiederherstellung, dann Übertragung in die Prod-Umgebung.

Kommunikation und Org. Struktur bei DR

Роли: Incident Commander, Tech Lead (Infra), DB Lead, App Lead, Comms, Security.
Kanäle: Backup (außerhalb der Unternehmensdomäne), Voice/Chat, SecureDocs.
Meldungsvorlagen: Kunden/Partner/Aufsichtsbehörden; Häufigkeit der Aktualisierungen; „Quelle der Wahrheit“.
Ein einziges Ereignisprotokoll: Zeitleiste, Lösungen, Besitzer.

DNS, Netzwerke und Datenverkehr

Split-Brain-Schutz: Flags „DR-Modus“ in der Konfiguration; feature-flags für eingeschränkte Funktionalität.
DNS-Strategie: niedrige TTL im Voraus, unabhängiger DNS-Anbieter; Stufenwechsel A/AAAA/CNAME, Aufwärmen des CDN.
Routing: Anycast/Geo, BGP-Ankündigung von DR-Website; ACLs/Firewalls werden von IaC neu zusammengestellt.

SLO für DR

RPO wird ≥ 99% der Zeit eingehalten (Log-Lag/Inkremente innerhalb des Ziels).
RTO Black-Start (vollständiges Szenario) ≤ Ziel (z. B. 4 Stunden) bei Tests einmal pro Quartal.
Erfolg der DR-Übungen - 100% der kritischen Aufgaben werden im Fenster erledigt.
Immutability - Anteil der Backups mit Retention/Lock = 100%.
Integritätsprüfungen - 100% nach Zeitplan; Verweigerung des Datenträgers → ein Migrationsticket.

Tests und Übungen

Table-top: Skripte, Rollen, Checklisten, Kontaktliste.
Technisch: selektive Wiederherstellung von DB/Dateien/Geheimnissen in die „Sandbox“ mit Prüfsummen- und Konsistenzprüfung.
Black-start-drill: einmal pro Quartal (oder einmal/sechs Monate) - vollständige Kernel-Einführung auf der DR-Website.
Post-mortem: Fakten, Engpässe, Verbesserungsplan (SLO/Prozesse/Automatisierung).

Automatisierung und Artefakte

IaC: Cluster, Netzwerke, Stacks - im Code; DR-Zweige/Parameter.
Runbooks: component (Vault/KMS, etcd, DB, Gateways, Fronten).
DR-Paket: Offline-Kopie der wichtigsten Docks (Kontakte, Schemata, Passwörter von Safe-Phrasen), Anweisungen für den physischen Zugriff.
Canary-restore: tägliche kleine Wiederherstellung und checksum Abgleich.
Tags/Tags: „DR-critical“, „Warm-only“, „Cold-only“ für Dienste/Volumes.

Checkliste für die Implementierung

• Die Datenklassen und deren RPO/RTO sind mit dem Unternehmen abgestimmt; Wiederherstellungsprioritäten wurden festgelegt.
• Implementierte Cold-Backups: Medien, Immutabilität (WORM/Object Lock), Offsite/Air-Gap.
• Verzeichnisse: Assets, Backups, Schlüssel; Scheckbeträge und Versionskontrolle.
• Black-Start-Verfahren: Netzwerke/DNS, IdP/Vault/KMS, Kontrollebene, Daten, Applayer.
• Übungen: Tabellenspitze vierteljährlich; kanarische Restore täglich; black-start mal/Quartal-sechs Monate.
• Kommunikations- und Regulierungsmuster; einzelnen Kommunikationskanälen.
• SLO/Metriken/Warnungen für DR; Berichte an das Management.
• Vereinbarungen mit Anbietern (Feeds/Archiv-Klassen/DNS/CDN), SLAs bestätigt.
• Finanzen: Medien-/Archivbudget, Logistik, Medientausch nach Terminen.

Typische Fehler

„Es gibt eine Replik - ein Backup ist nicht erforderlich“ → ein logischer Fehler/Ransomware wird überall verschwinden.
Es gibt keine Immutabilität/Air-Gap → einen einzigen Kompromittierungsvektor für alle Kopien.
Das Fehlen von Katalogen/Checksummen → „etwas“ wiederhergestellt, aber nicht das.
TTL DNS ist zu groß → mehrtägige Datenverkehrsmigration.
Schlüssel/KMS in derselben Domain/demselben Konto → Sperrung des Zugriffs bei einem Vorfall.
Übungen nur „auf dem Papier“ → RTO/RPO sind nicht bestätigt.

Spezifität für iGaming/Fintech

Wallet/Payment Core: strenge RPO (≤ 1-5 min) und RTO (≤ 15-60 min); Protokolle in ein Objekt mit WORM; DR-Funktion „read-only balance“ für transparente Kommunikation.
PSPs/Content Provider: vorab vereinbarte DR-IP/Domain, Whitelists, Zertifikate, HMAC/mTLS-Schlüssel - Kopien im DR-Paket.
Reporting/Regulatoren: Benachrichtigungsvorlagen, unveränderliche Archive, nachweisbare Integrität, Aktivitätsprotokoll.
Peaks und Events: DR-Ready wird vor großen Turnieren/Aktionen getestet; kanarische Wiederherstellung und Aufwärmen des CDN.

Mini-Runbook-Vorlagen

1. Initialisierung des DR-Clusters, Laden von unseal-Schlüsseln (Dual-Control).

2. Wiederherstellung eines Storage-Backups (Cold-Copy).

3. Überprüfung von Richtlinien, Ausgabe von Bootstrap-Geheimnissen für CI/CD/K8s.

1. Erweitern Sie eine leere Instance, stellen Sie eine vollständige Instance aus cold wieder her.

2. Legen Sie WAL-Protokolle (Inkremente) bis zum Zielpunkt ab.

3. Consistency Check, aktivieren Sie die Replikation, öffnen Sie read-only, dann read-write.

1. Reduzieren Sie die TTL 24-72 Stunden vor den geplanten Risiken (oder halten Sie sie konstant niedrig).

2. A/AAAA/CNAME-Umschaltung über Checkliste, Fehler-/Latenzüberwachung.

3. Allmähliche Zunahme des Verkehrs (Kanarienvogel 5% → 25% → 100%).

Ergebnis

Eine zuverlässige DR, die auf kalten Backups basiert, ist: immutable isolierte Kopien, formalisierte Black-Start-Verfahren, klare RPO/RTOs, regelmäßige Übungen, eine durchdachte DNS/Netzwerkstrategie und Schlüsseldisziplin. Erfassen Sie alles in IaC- und Runbooks, automatisieren Sie Integritätsprüfungen und kanarische Wiederherstellungen - und Sie haben auch nach dem Worst-Case-Szenario immer einen kontrollierten Wiederherstellungspfad.