Disaster Recovery
Disaster Recovery
Sicherstellung der Geschäftskontinuität nach Ausfällen, Naturkatastrophen oder Cyberangriffen. Von RTO/RPO-Kennzahlen über Hot/Cold Sites bis zum kompletten DR-Plan.
Inhaltsverzeichnis
Schnellübersicht
Auf dieser Seite lernst du alles über Disaster Recovery (DR) im Enterprise-Umfeld:
- Definition: Was ist Disaster Recovery und wie unterscheidet es sich von Backup?
- Kennzahlen: RTO, RPO, MAO und WRT im Detail
- DR-Strategien: Cold, Warm, Hot Site, Pilot Light und Active/Active
- Technologien: Snapshots, Replikation, CDP
- Der DR-Plan: 5 Phasen von der Analyse bis zur Wartung
- Strategie-Simulator: Interaktive Empfehlung für deine Umgebung
- Best Practices: 3-2-1-Regel, Testing, Dokumentation
- FAQ: Häufige Fragen zu Disaster Recovery
1. Was ist Disaster Recovery?
Definition
Disaster Recovery (DR) umfasst alle Maßnahmen, Prozesse und Technologien, die darauf abzielen, die IT-Infrastruktur und Geschäftsprozesse nach einem schwerwiegenden Ausfall (z.B. Naturkatastrophe, Cyberangriff, Hardware-Totalausfall) schnellstmöglich wiederherzustellen.
Unterschied zu Backup: Ein Backup ist eine Kopie der Daten. Disaster Recovery ist der gesamte Plan und Prozess, um diese Daten (und die darauf laufenden Systeme) im Ernstfall tatsächlich wieder nutzbar zu machen. Backup ist ein Teil von DR, aber DR ist viel mehr als nur Backup.
Business Continuity vs. Disaster Recovery
- Business Continuity (BCP): Umfassender Plan, um das gesamte Geschäft (inkl. Personal, Kommunikation, alternative Standorte) am Laufen zu halten.
- Disaster Recovery (DRP): Spezifischer Teil des BCP, der sich ausschließlich auf die Wiederherstellung der IT-Systeme und Daten konzentriert.
2. Die 4 wichtigsten DR-Kennzahlen
Jeder DR-Plan basiert auf vier zentralen Metriken, die in einer Business Impact Analysis (BIA) ermittelt werden:
RTO
Die maximal akzeptable Ausfallzeit eines Systems. Wie schnell muss das System nach einem Ausfall wieder laufen? (Zielzeit)
RPO
Der maximal akzeptable Datenverlust. Wie alt darf die letzte Sicherung sein, die wiederhergestellt wird? (Zeitpunkt)
MAO
Die absolute Obergrenze der Ausfallzeit, bevor das Unternehmen existenzielle Schäden erleidet. RTO muss immer < MAO sein.
WRT
Die Zeit, die benötigt wird, um Daten nach der Systemwiederherstellung zu validieren, zu konfigurieren und den Betrieb vollständig aufzunehmen.
Die RTO/RPO-Formel
RTO + WRT ≤ MAO
Die Zeit zur Wiederherstellung (RTO) plus die Zeit zur Nachbearbeitung (WRT) darf die maximal akzeptable Ausfallzeit (MAO) nicht überschreiten.
3. Disaster Recovery Strategien
Die Wahl der DR-Strategie hängt direkt von den geforderten RTO- und RPO-Werten sowie dem verfügbaren Budget ab.
Cold Site
Ein leerer Raum mit Strom, Kühlung und Netzwerkanschluss. Hardware und Daten müssen im Ernstfall erst geliefert und installiert werden.
- RTO: Tage bis Wochen
- RPO: Abhängig vom letzten Backup
- Sehr geringe laufende Kosten
Warm Site
Hardware ist vorinstalliert und betriebsbereit. Daten werden regelmäßig (z.B. täglich) synchronisiert, aber das System läuft nicht aktiv.
- RTO: Stunden bis Tage
- RPO: Stunden (letztes Backup)
- Moderate laufende Kosten
Hot Site
Exakte Kopie der Produktionsumgebung. Daten werden in Echtzeit oder nahezu in Echtzeit repliziert. Kann innerhalb von Minuten übernehmen.
- RTO: Minuten bis Stunden
- RPO: Nahezu 0 (wenige Minuten)
- Hohe laufende Kosten
Pilot Light
Nur die kritischsten Kernkomponenten (z.B. Datenbank) laufen ständig in der Cloud. Im Notfall werden Web- und App-Server schnell hochskaliert.
- RTO: Minuten
- RPO: Minuten (Replikation)
- Kosteneffizient (Pay-as-you-go)
Multi-Site Active/Active
Identische Umgebungen an mehreren Standorten, die gleichzeitig aktiv sind und den Traffic teilen. Fällt ein Standort aus, übernehmen die anderen nahtlos.
- RTO: Nahezu 0 (Sekunden)
- RPO: 0 (synchrone Replikation)
- Sehr hohe Kosten und Komplexität
4. DR-Technologien im Überblick
| Technologie | Funktionsweise | RPO | RTO | Einsatzgebiet |
|---|---|---|---|---|
| Traditionelles Backup | Voll-/Inkrementell auf Band oder Disk | Stunden bis Tage | Stunden bis Tage | Langzeitarchivierung, Cold Sites |
| Snapshots | Point-in-Time-Kopie des Volumes | Minuten bis Stunden | Minuten | Schnelle Wiederherstellung von VMs |
| Asynchrone Replikation | Daten werden mit leichter Verzögerung kopiert | Minuten | Minuten bis Stunden | Geo-Redundanz über große Distanzen |
| Synchrone Replikation | Schreibvorgang erst erfolgreich, wenn an beiden Orten gespeichert | 0 (kein Datenverlust) | Minuten | Kritische Datenbanken, kurze Distanzen |
| CDP (Continuous Data Protection) | Jede einzelne Änderung wird in Echtzeit protokolliert | Nahezu 0 (Sekunden) | Minuten | Höchste Anforderungen an Datenintegrität |
5. Der Disaster Recovery Plan (DRP)
Ein DRP ist ein lebendiges Dokument, das in 5 klar definierten Phasen erstellt und gepflegt wird.
Business Impact Analysis (BIA)
Identifikation kritischer Geschäftsprozesse. Ermittlung von RTO, RPO und MAO für jedes System. Bewertung der finanziellen und operativen Auswirkungen eines Ausfalls.
Strategieentwicklung
Auswahl der passenden DR-Strategie (Cold/Warm/Hot Site, Cloud) basierend auf den BIA-Ergebnissen und dem verfügbaren Budget. Definition von Verantwortlichkeiten.
Implementierung
Aufbau der Infrastruktur, Einrichtung von Replikation, Konfiguration von Backups und Erstellung detaillierter, schrittweiser Wiederherstellungsanleitungen (Runbooks).
Testing & Übung
Regelmäßige Tests des DR-Plans (Tabletop-Exercises, simulierte Ausfälle, vollständige Failover-Tests). Nur ein getesteter Plan ist ein zuverlässiger Plan.
Wartung & Aktualisierung
Kontinuierliche Anpassung des Plans an neue Systeme, geänderte Geschäftsprozesse, Personalwechsel und Lessons Learned aus Tests oder echten Incidents.
6. Interaktiver DR-Strategie-Simulator
Wähle die Parameter deines Systems aus, um eine empfohlene Disaster Recovery Strategie zu erhalten.
Strategie-Empfehlung
System-Parameter
Empfehlung
7. Best Practices für Disaster Recovery
Die 3-2-1-Regel
- 3 Kopien der Daten (1x Produktion + 2x Backup)
- 2 verschiedene Speichermedien (z.B. Disk + Band/Cloud)
- 1 Kopie an einem externen Standort (Offsite)
Regelmäßiges Testing
- Mindestens 1-2 mal pro Jahr vollständige DR-Tests
- Tabletop-Exercises für das Management
- Automatisierte Failover-Tests wo möglich
- Dokumentation aller "Lessons Learned"
Dokumentation & Runbooks
- Schritt-für-Schritt-Wiederherstellungsanleitungen
- Kontaktlisten (intern und extern) immer aktuell
- Physische Kopie des DR-Plans außerhalb des Hauptstandorts
Automatisierung
- Automatisierte Backup-Verifizierung
- Infrastructure as Code (IaC) für schnelles Provisioning
- Automatisierte Failover-Skripte reduzieren menschliche Fehler
Cloud & Geo-Redundanz
- Nutzung von Cloud-Regionen für kosteneffiziente Warm/Hot Sites
- Unveränderliche (Immutable) Backups gegen Ransomware
- Getrennte Identitäts- und Zugriffsverwaltung für DR-Accounts
Team & Kommunikation
- Klare Rollenzuweisung (DR-Manager, Tech-Leads)
- Vertretungsregelungen für Schlüsselpersonal
- Kommunikationsplan für Stakeholder und Kunden
8. FAQ – Häufige Fragen
Häufige Fragen zu Disaster Recovery
RTO (Recovery Time Objective) bezieht sich auf die Zeit: Wie schnell muss das System nach einem Ausfall wieder verfügbar sein? (z.B. "innerhalb von 4 Stunden").
RPO (Recovery Point Objective) bezieht sich auf die Daten: Wie viel Datenverlust ist akzeptabel? Es definiert den Zeitpunkt des letzten Backups. (z.B. "maximal 1 Stunde Datenverlust").
Nein, nicht allein. Ein Cloud-Backup ist nur die Datengrundlage. Disaster Recovery umfasst auch den Plan, die Infrastruktur (Server, Netzwerk), die Prozesse und die Tests, um diese Daten tatsächlich wieder in einen betriebsbereiten Zustand zu versetzen. Backup ist eine Voraussetzung für DR, aber nicht der gesamte DR-Prozess.
Mindestens einmal pro Jahr sollte ein umfassender Test (z.B. ein simulierter Failover) durchgeführt werden. Zusätzlich sollten vierteljährlich "Tabletop-Exercises" (durchgespielte Szenarien im Team) und regelmäßige, automatisierte Tests einzelner Komponenten (z.B. Wiederherstellung einer einzelnen VM) stattfinden.
Immutable Backups (unveränderliche Sicherungen) können nach der Erstellung für einen festgelegten Zeitraum weder geändert noch gelöscht werden – nicht einmal von Administratoren. Dies ist die wirksamste Verteidigung gegen Ransomware, da Angreifer die Backups nicht verschlüsseln oder löschen können, um Lösegeld zu erpressen.
Failover ist der Wechsel vom ausgefallenen Primärsystem zum DR-System. Failback ist der umgekehrte Prozess: Sobald das Primärsystem repariert ist, werden die während des Ausfalls im DR-System angefallenen Daten zurück synchronisiert und der Betrieb wird wieder auf das ursprüngliche System verlagert. Failback ist oft komplexer als der initiale Failover.
Der DR-Plan muss selbst Teil der DR-Strategie sein:
- Physische Ausdrucke an sicheren, externen Orten lagern
- Digitale Kopien in einem vom Hauptnetzwerk getrennten, sicheren Cloud-Speicher
- Zugriff für das DR-Team auch ohne Zugriff auf das aktive Directory (z.B. über Notfall-Accounts)
Zusammenfassung
Die wichtigsten Punkte
- DR vs. Backup: Backup ist die Datenkopie, DR ist der gesamte Prozess zur Wiederherstellung des Betriebs.
- Kennzahlen: RTO (Zeit bis zur Wiederherstellung), RPO (akzeptabler Datenverlust), MAO (maximale Ausfallzeit).
- Strategien: Cold Site (günstig, langsam) bis Active/Active (teuer, sofortige Verfügbarkeit).
- Technologien: Snapshots, synchrone/asynchrone Replikation und CDP für minimale RPOs.
- DR-Plan: BIA → Strategie → Implementierung → Testing → Wartung.
- 3-2-1-Regel: 3 Kopien, 2 Medien, 1 externer Standort (plus Immutable Backups gegen Ransomware).
- Testing: Ein ungetesteter DR-Plan ist kein DR-Plan. Regelmäßige Übungen sind Pflicht.
Weiterführende Themen
Backup-Strategien, Medien, Methoden und die 3-2-1-Regel im Detail.
Zu Backup & RecoveryClustering, Load Balancing und Redundanz zur Vermeidung von Ausfällen.
Zu HochverfügbarkeitWie Cloud-Provider DR durch Multi-Region-Deployments vereinfachen.
Zur Cloud-InfrastrukturSchutz vor Ransomware und anderen Bedrohungen, die DR auslösen.
Zur IT-Sicherheit