3 Min. Lesezeit
Das Wichtigste in Kürze
- RTO (Recovery Time Objective) und RPO (Recovery Point Objective) bestimmen das DR-Design.
- Multi-Region Active-Active liefert RTO < 1 Minute, kostet aber das 2-3-fache.
- Pilot Light und Warm Standby bieten kosteneffiziente DR mit RTO von 10-60 Minuten.
- Infrastructure as Code macht DR-Umgebungen reproduzierbar und testbar.
- Regelmäßige DR-Tests sind Pflicht – 40% der Unternehmen, die nicht testen, scheitern im Ernstfall.
Die Frage ist nicht ob, sondern wann eine Cloud-Region ausfällt. AWS us-east-1, Azure South Central und GCP europe-west1 hatten alle in den letzten Jahren signifikante Ausfälle. Unternehmen, die keinen getesteten Disaster-Recovery-Plan haben, stehen dann vor der existenziellen Frage: Wie schnell können wir wieder online sein – und wie viele Daten haben wir verloren?
RTO und RPO: Die beiden Kennzahlen, die alles bestimmen
Recovery Time Objective (RTO) beantwortet: Wie lange darf der Ausfall maximal dauern? Ein RTO von 4 Stunden bedeutet: Innerhalb von 4 Stunden nach einem Ausfall muss der Service wieder laufen.
Recovery Point Objective (RPO) beantwortet: Wie viel Datenverlust ist akzeptabel? Ein RPO von 1 Stunde bedeutet: Maximal die letzte Stunde an Daten darf verloren gehen.
Beide Kennzahlen bestimmen das DR-Design und die Kosten. RTO 0 und RPO 0 erfordern Active-Active Multi-Region – die teuerste Option. RTO 24h und RPO 24h reichen mit täglichen Backups – die günstigste. Die Kunst liegt in der richtigen Balance zwischen Business-Anforderung und Budget.
Die vier DR-Strategien in der Cloud
Backup & Restore: Regelmäßige Backups in eine andere Region. Im DR-Fall: Infrastruktur aufbauen, Backups einspielen. RTO: 4-24 Stunden. RPO: Je nach Backup-Frequenz. Kosten: Minimal (nur Storage für Backups). Geeignet für nicht-kritische Workloads.
Pilot Light: Minimale Infrastruktur (Datenbank-Replika, DNS) läuft permanent in der DR-Region. Im DR-Fall: Compute-Ressourcen hochfahren, Traffic umleiten. RTO: 30-60 Minuten. RPO: Minuten (durch Replikation). Kosten: 10-20% der Produktionskosten.
Warm Standby: Skalierte Version der Produktion läuft in der DR-Region mit reduzierter Kapazität. Im DR-Fall: Hochskalieren und Traffic umleiten. RTO: 10-30 Minuten. RPO: Sekunden. Kosten: 30-50% der Produktionskosten.
Active-Active Multi-Region: Volle Kapazität in beiden Regionen, Traffic wird verteilt. Ausfall einer Region wird automatisch kompensiert. RTO: < 1 Minute. RPO: 0. Kosten: 200-300% (plus Komplexität). Geeignet für geschäftskritische, kundennahe Services.
Infrastructure as Code als DR-Enabler
DR-Pläne, die auf manuellen Runbooks basieren, scheitern im Ernstfall an Stress, Zeitdruck und fehlenden Zugangsdaten. Infrastructure as Code (Terraform, CloudFormation, Pulumi) macht DR-Umgebungen deklarativ und reproduzierbar.
Das Muster: Die Produktionsinfrastruktur ist vollständig in Code beschrieben. Im DR-Fall wird derselbe Code in der Zielregion ausgeführt – mit regionspezifischen Variablen. Was manuell Stunden dauert, ist mit IaC in Minuten erledigt. Und testbar: DR-Drills werden regelmäßig ausgeführt, um sicherzustellen, dass der Code funktioniert.
Daten-Replikation: Synchron vs. Asynchron
Synchrone Replikation schreibt Daten gleichzeitig in beide Regionen. RPO: 0 (kein Datenverlust). Nachteil: Latenz steigt, weil jeder Write auf Bestätigung aus der DR-Region warten muss. Nur sinnvoll bei Regionen mit < 50ms Latenz.
Asynchrone Replikation schreibt zuerst lokal und repliziert verzögert. RPO: Sekunden bis Minuten (je nach Replication Lag). Vorteil: Keine Latenz-Impact auf die Produktion. Standard für Cross-Region-DR.
Managed Services wie Aurora Global Database, Cosmos DB und Cloud Spanner bieten Multi-Region-Replikation mit konfigurierbarer Konsistenz – der Betriebsaufwand für eigene Replikations-Setups entfällt.
DR-Testing: Der unterschätzte Erfolgsfaktor
Ein DR-Plan, der nicht getestet wird, ist kein Plan – es ist eine Hoffnung. Studien zeigen: 40% der Unternehmen, die ihren DR-Plan nie getestet haben, scheitern im Ernstfall an unvorhergesehenen Problemen. Abgelaufene Credentials, geänderte API-Endpunkte, inkompatible Datenformate – alles Probleme, die nur durch Tests sichtbar werden.
Best Practice: Quartalsweise DR-Drills, bei denen die DR-Region tatsächlich Traffic übernimmt. Netflix hat mit „Chaos Engineering“ (Chaos Monkey, regional Outage-Simulation) vorgemacht, wie man Ausfallsicherheit kontinuierlich testet. AWS Fault Injection Service und Azure Chaos Studio bieten Managed Chaos Engineering für alle.
Häufige Fragen
Was kostet Disaster Recovery in der Cloud?
Je nach Strategie: Backup & Restore kostet nur Storage (wenige Euro/Monat pro TB). Pilot Light 10-20% der Produktionskosten. Warm Standby 30-50%. Active-Active 200-300%. Für die meisten Mittelständler ist Pilot Light der Sweet Spot zwischen Kosten und Verfügbarkeit.
Wie oft sollte man DR testen?
Mindestens vierteljährlich. Kritische Systeme monatlich. Jeder Test sollte dokumentiert werden: Was hat funktioniert, was nicht, welche Maßnahmen sind nötig. Automatisierte DR-Tests (via Terraform + CI/CD) ermöglichen häufigere Tests ohne manuellen Aufwand.
Reicht ein Backup als DR-Strategie?
Für nicht-kritische Systeme ja. Für alles, was einen RTO unter 4 Stunden braucht, reichen Backups nicht – der Restore-Prozess dauert zu lange. Datenbanken mit vielen Terabyte brauchen Stunden zum Einspielen. Pilot Light oder Warm Standby sind dann die bessere Wahl.
Was passiert bei einem Multi-Region-Ausfall?
Multi-Region-Ausfälle bei einem einzelnen Provider sind extrem selten, aber möglich (DNS-Ausfall, globaler IAM-Bug). Für maximale Resilienz setzen Unternehmen auf Multi-Cloud-DR – Produktion bei AWS, DR bei Azure oder umgekehrt. Die Komplexität ist erheblich, aber für kritische Infrastruktur gerechtfertigt.
Wie plane ich DR für Kubernetes-Workloads?
Velero ist der Standard für Kubernetes-DR: Es sichert Cluster-State und Persistent Volumes und kann in eine andere Region oder einen anderen Cluster restoren. Für stateless Workloads reicht GitOps (ArgoCD): Der Cluster-State ist im Git-Repository definiert und kann jederzeit in einem neuen Cluster deployed werden.
Quelle des Titelbildes: Pexels / Jakub Zerdzicki
Lesetipps der Redaktion
- Lenovo ThinkCentre M75q Tiny Gen 5: Enterprise-Mini-PC mit AMD PRO und 5 Watt Idle für Edge und Kiosk
- Serverless KI ist überbewertet – hier ist was stattdessen zählt
- QNAP TS-464: 4-Bay-NAS mit Docker, HDMI und PCIe-Slot – was Synology in dieser Klasse nicht bietet
