Disaster Recovery (DR) bezeichnet die Gesamtheit aller Maßnahmen, Prozesse und Systeme, die sicherstellen, dass eine Organisation nach einem schwerwiegenden Ausfallereignis – Rechenzentrum-Brand, Cyberangriff, Naturkatastrophe, massiver Hardwareausfall – ihre IT-Systeme und damit ihre Geschäftstätigkeit in angemessener Zeit wieder aufnehmen kann. DR geht über Backup und Failover hinaus: Es ist ein vollständiger Plan, der definiert, wer was tut, wenn das Schlimmste eintritt.
Disaster Recovery unterscheidet sich von Hochverfügbarkeit durch die Schwere der behandelten Ereignisse: HA schützt vor einem einzelnen Komponentenausfall (ein Server fällt aus). DR schützt vor Katastrophen (das gesamte Rechenzentrum ist nicht mehr erreichbar). Beide sind notwendig und ergänzen sich.
Die zwei zentralen DR-Kennzahlen: RTO und RPO
RTO (Recovery Time Objective) – die maximal tolerierbare Ausfallzeit: Wie lange darf das System ausfallen, bevor der Schaden nicht mehr akzeptabel ist? RPO (Recovery Point Objective) – der maximal tolerierbare Datenverlust: Wie viele Stunden oder Minuten an Daten dürfen bei einer Wiederherstellung verloren gehen? Beide Kennzahlen müssen vor der DR-Planung mit dem Business definiert werden – sie bestimmen direkt die Kosten der DR-Architektur.
DR-Strategien nach RTO und RPO
| Strategie | RTO | RPO | Kosten |
| Backup & Restore | Stunden–Tage | Stunden–Tage | Minimal |
| Pilot Light | 10–60 Min. | Minuten | Niedrig |
| Warm Standby | Minuten | Sekunden–Min. | Mittel |
| Multi-Site Active | Sekunden | Nahe null | Hoch |
DR für Automatisierungsplattformen
- Workflow-Definitionen in Git: Alle Workflow-Konfigurationen sind versioniert – nach einem Totalverlust in Minuten wiederherstellbar
- Infrastructure as Code: Die gesamte Infrastruktur ist als Code (Terraform, Ansible) definiert – ein neues System kann in Minuten aus dem Code provisioniert werden
- Dokumentiertes Runbook: Step-by-Step-Anleitung für den Wiederherstellungsfall – auch für Personen, die das System nicht täglich betreuen
- Regelmäßige DR-Tests: Der Plan wird quartalsweise geprobt – nur ein getesteter DR-Plan ist ein verlässlicher DR-Plan
Praxisbeispiel
Ein Automationsdienstleister entwickelt einen DR-Plan für seine gesamte Plattform. Definierte Ziele: RTO 2 Stunden, RPO 4 Stunden. DR-Strategie (Warm Standby): In AWS Region eu-central-1 (Frankfurt) läuft die Produktionsumgebung. In eu-west-1 (Irland) läuft eine reduzierte Standby-Umgebung mit synchronisierten Datenbank-Snapshots alle 4 Stunden. Im Katastrophenfall: Standby-Umgebung wird auf volle Kapazität hochgefahren (Infrastructure as Code), DNS auf neue Region umgeleitet. Workflow-Definitionen aus Git geladen. Geschätzte Wiederherstellungszeit: 45 Minuten. DR-Test letztes Quartal: 52 Minuten. Erkenntnisse aus dem Test: DNS-TTL auf 60 Sekunden reduzieren (war noch auf 300 Sekunden).
