Disaster Recovery (DR), auf Deutsch Notfallwiederherstellung, bezeichnet die geplante technische Wiederherstellung von IT-Systemen, Anwendungen und Daten nach einem schwerwiegenden Ausfall – etwa durch Ransomware, Rechenzentrumsausfall, Hardwaredefekt oder Naturereignis. Disaster Recovery arbeitet mit vorab festgelegten Wiederherstellungszielen, insbesondere Recovery Time Objective (RTO) und Recovery Point Objective (RPO), sowie dokumentierten und geübten Wiederherstellungsplänen. Maßgebliche Bezugspunkte sind ISO/IEC 27031, der BSI-Standard 200-4 und NIST SP 800-34.

Was ist Disaster Recovery?

Disaster Recovery ist die Gesamtheit der Verfahren, Ressourcen und Pläne, mit denen eine Organisation ausgefallene IT-Systeme und verlorene Daten nach einem gravierenden Ereignis in einen definierten Betriebszustand zurückführt.

Der Begriff beschreibt bewusst die technische Ebene: Server, Netzwerke, Datenbanken, Anwendungen, Konfigurationen und Datenbestände. Wie die Fachbereiche in der Zwischenzeit arbeiten, regelt nicht Disaster Recovery, sondern das übergeordnete Kontinuitätsmanagement.

Charakteristisch für Disaster Recovery ist die Vorabfestlegung von Zielwerten. Zwei Fragen müssen vor dem Ereignis beantwortet sein:

Wie lange darf ein System ausfallen (Recovery Time Objective) und wie viele Daten dürfen verloren gehen (Recovery Point Objective)?

Aus diesen Vorgaben leiten sich alle technischen Entscheidungen ab – Backup-Frequenz, Replikationsverfahren, Standby-Kapazitäten, Standortwahl. Wer die Zielwerte nicht kennt, kann keine Architektur dimensionieren, sondern nur hoffen.

Ein zweites Merkmal ist der Ausnahmecharakter. Disaster Recovery greift nicht bei einer einzelnen defekten Festplatte, sondern wenn der Betrieb in einer Umgebung nicht fortgeführt werden kann und auf eine Ausweichlösung umgeschaltet werden muss. Diese Umschaltung – der Failover – ist ein formal ausgelöster Vorgang mit benannter Entscheidungsbefugnis. Disaster Recovery ist damit immer beides: technische Fähigkeit und geregeltes Verfahren.

Warum ist Disaster Recovery wichtig?

Disaster Recovery ist wichtig, weil die Wiederherstellungsfähigkeit heute häufiger über den Schaden entscheidet als die Abwehrfähigkeit. Ransomware verschlüsselt produktive Systeme und Backups innerhalb von Stunden, Cloud- und Netzwerkabhängigkeiten bündeln Ausfallrisiken an wenigen Punkten, und Extremwetterereignisse treffen Rechenzentrumsstandorte, die früher als unkritisch galten. Vollständige Prävention ist unter diesen Bedingungen keine belastbare Annahme mehr.

Der wirtschaftliche Schaden einer IT-Unterbrechung entsteht selten linear. In den ersten Stunden lassen sich Ausfälle oft improvisiert überbrücken. Danach steigt der Schaden überproportional, weil Termine nicht eingehalten werden können, Vertragsstrafen greifen, Kunden ausweichen und Aufsichtsbehörden Auskunft verlangen. Für Betreiber kritischer Infrastrukturen bemisst sich der Schaden zudem nicht nur in Geld, weil ihre Leistungen unmittelbar für Versorgung, Sicherheit und Gesundheit relevant sind.

Hinzu kommt der Nachweischarakter: Ob eine Organisation vorbereitet war, prüfen Versicherer, Wirtschaftsprüfer, Aufsichtsbehörden und im Streitfall Gerichte regelmäßig nach einem Vorfall. Erfahrungsgemäß ist dabei nicht das Vorhandensein eines Plans die kritische Frage, sondern der Zeitpunkt des letzten dokumentierten Wiederherstellungstests.

Wie unterscheidet sich Disaster Recovery von Backup, Hochverfügbarkeit und BCM?

Disaster Recovery unterscheidet sich von den Nachbardisziplinen durch seinen Gegenstand: Backup sichert Datenkopien, Hochverfügbarkeit verhindert Ausfälle im laufenden Betrieb, Business Continuity Management organisiert die Handlungsfähigkeit der gesamten Organisation. Und Disaster Recovery stellt Technik und Daten nach einem eingetretenen Ausfall wieder her. Die Begriffe werden häufig synonym verwendet, was in der Praxis zu Lücken führt.

Disziplin	Fokus	Verhältnis zu Disaster Recovery
Backup	Erstellung und Aufbewahrung von Datenkopien	Voraussetzung, nicht Ersatz: Ein Backup ohne geprüftes Wiederherstellungsverfahren ist kein Disaster Recovery
Hochverfügbarkeit (HA)	Vermeidung von Ausfällen durch Redundanz im Normalbetrieb, meist innerhalb eines Standorts	Ergänzend: HA trägt Einzelkomponentenausfälle, Disaster Recovery den Verlust ganzer Umgebungen
IT-Service-Continuity-Management (ITSCM)	Kontinuität und Verfügbarkeit der IT-Services insgesamt	Übergeordnet: Disaster Recovery ist die Umsetzungsebene innerhalb des ITSCM
Business Continuity Management (BCM)	Fortführung zeitkritischer Geschäftsprozesse, inklusive Personal, Gebäude und Dienstleistern	Übergeordnet: BCM liefert die Zeitvorgaben, Disaster Recovery erfüllt sie technisch
Notfall- und Krisenmanagement	Akute Ereignisbewältigung, Entscheidungen im Krisenstab	Parallel: Der Krisenstab entscheidet, Disaster-Recovery-Teams führen aus

Praktisch bedeutet diese Abgrenzung: Wer ausschließlich Hochverfügbarkeit betreibt, übersteht Komponentenausfälle, aber keine logische Zerstörung der Daten. Wer ausschließlich Backups vorhält, besitzt Daten, aber keine Zielumgebung und keine Wiederanlaufreihenfolge. Disaster Recovery verbindet Datensicherung, Zielinfrastruktur und Verfahren zu einer belastbaren Wiederherstellungsfähigkeit.

Welche Kennzahlen nutzt Disaster Recovery?

Die zentralen Kennzahlen im Disaster Recovery übersetzen fachliche Ausfalltoleranzen in messbare technische Vorgaben. Sie stammen in der Regel aus der Business-Impact-Analyse und bilden die Schnittstelle zwischen Fachbereich und IT.

Kennzahl	Bedeutung
RTO	Recovery Time Objective: Zeitspanne, innerhalb der ein System nach dem Ausfall wieder verfügbar sein muss
RPO	Recovery Point Objective: maximal tolerierbarer Datenverlust, ausgedrückt als Zeitraum vor dem Ereignis
MTD/MTPD	Maximum Tolerable Downtime bzw. Maximum Tolerable Period of Disruption: Ausfalldauer, ab der der Schaden nicht mehr akzeptabel ist; RTO muss darunter liegen
WRT	Work Recovery Time: Zeit für Datenabgleich, Nacherfassung und Freigabe nach der technischen Wiederherstellung; RTO + WRT ≤ MTD
MTTR	Mean Time To Repair/Recover: durchschnittliche Wiederherstellungsdauer aus dem Regelbetrieb, als Erfahrungswert für die Planung
RTA/RPA	Recovery Time/Point Actual: die im Test oder Ereignis tatsächlich erreichten Werte – die eigentliche Prüfgröße

Die Unterscheidung zwischen Zielwert und Istwert ist der wunde Punkt vieler Konzepte. Ein RTO von vier Stunden ist eine Anforderung. Ob sie erfüllbar ist, zeigt erst die gemessene Recovery Time Actual in einer realistischen Wiederherstellung.

Ebenso wichtig ist die Work Recovery Time: Ein System kann technisch verfügbar sein, während der Fachbereich noch Stunden benötigt, um Belege nachzuerfassen und den Datenstand zu verifizieren. Wird dieser Anteil nicht eingeplant, sind die zugesagten Zeiten systematisch zu optimistisch.

Was gehört in einen Disaster-Recovery-Plan (DRP)?

Ein Disaster-Recovery-Plan (DRP) enthält alle Informationen, die ein Wiederherstellungsteam benötigt, um unter Zeitdruck und ohne Zugriff auf die ausgefallene Umgebung handlungsfähig zu sein. Entscheidend ist nicht der Umfang, sondern die Benutzbarkeit im Ereignisfall: kurz, aktuell, eindeutig und offline verfügbar.

Geltungsbereich und Auslösekriterien: Welche Systeme deckt der Plan ab und wann greift er?
Rollen und Entscheidungsbefugnisse: Wer erklärt den Notfall, wer löst den Failover aus, wer gibt was frei, inklusive Vertretungen?
Priorisierte Wiederanlaufreihenfolge: Systeme mit RTO und RPO, geordnet nach technischen Abhängigkeiten.
Technische Wiederherstellungsanweisungen: Schritt für Schritt, mit Speicherorten von Images, Backups, Schlüsseln, Lizenzen und Konfigurationen.
Alarmierungs- und Kommunikationswege: Erreichbarkeiten rund um die Uhr, Eskalationsstufen, Kommunikation mit Dienstleistern.
Abhängigkeiten von Dritten: Cloud-Anbieter, Rechenzentrumsbetreiber, Wartungsverträge, zugesicherte Reaktionszeiten.
Prüf- und Freigabekriterien: Wie Integrität und Funktionsfähigkeit vor der Rückgabe an die Fachbereiche verifiziert werden

Ein wiederkehrender Fehler ist die Ablage: Liegt der Disaster-Recovery-Plan ausschließlich im Dateisystem, im Intranet oder im Ticketsystem, ist er nach einem Verschlüsselungsvorfall genau dann unerreichbar, wenn er gebraucht wird. Gleiches gilt für Passwortsafes und Notfallkontaktlisten. Bewährt hat sich eine geprüfte Offline-Kopie an definierten Orten, deren Aktualität Teil des Plans selbst ist.

Welche Disaster-Recovery-Strategien gibt es?

Disaster-Recovery-Strategien unterscheiden sich darin, wie viel Infrastruktur eine Organisation für den Notfall vorhält und damit direkt in erreichbarem RTO, RPO und Kosten. Die Auswahl ist keine technische Vorliebe, sondern eine Ableitung aus den fachlichen Zeitvorgaben.

Strategie	Prinzip	Typisches RTO	Aufwand
Backup & Restore	Wiederherstellung aus Datensicherung auf neu bereitgestellte Systeme	Tage	niedrig
Cold Standby/Cold Site	Vorbereiteter Standort ohne laufende Systeme	Tage	niedrig bis mittel
Pilot Light	Kernkomponenten laufen minimal mit, Skalierung im Ereignisfall	Stunden	mittel
Warm Standby/Warm Site	Reduziert dimensionierte, laufende Zweitumgebung mit fortlaufender Replikation	Minuten bis Stunden	hoch
Hot Site/Active-Active	Zwei vollwertige, parallel produktive Standorte	Sekunden bis Minuten	sehr hoch

Die Datenseite wird separat dimensioniert. Für Backups gilt weiterhin die 3-2-1-Regel: drei Datenkopien auf zwei unterschiedlichen Medientypen, davon eine an einem anderen Standort.

Angesichts der Bedrohungslage wird sie häufig zu 3-2-1-1-0 erweitert – eine Kopie offline oder unveränderbar (Air Gap beziehungsweise Immutability/WORM) und null Fehler im Wiederherstellungstest. Für kurze RPO kommt Replikation hinzu, wobei synchrone Replikation Datenverlust nahezu ausschließt, aber Distanz und Latenz begrenzt, während asynchrone Replikation größere Entfernungen erlaubt und einen definierten Restverlust in Kauf nimmt.

Bei der Standortwahl ist Georedundanz die zentrale Größe. Das BSI empfiehlt in seinen Kriterien für die Standortwahl georedundanter Rechenzentren einen Abstand von mindestens 200 Kilometern und lässt geringere Distanzen nur mit Begründung und Risikoanalyse zu – die Untergrenze liegt bei 100 Kilometern. Hintergrund ist die Reichweite regionaler Ereignisse wie Hochwasser, Stromnetzstörungen oder großflächige Netzausfälle: Zwei Rechenzentren im Umkreis von wenigen Kilometern sind gegen Komponentenausfälle geschützt, gegen ein regionales Ereignis jedoch nicht.

Wie läuft die Disaster Recovery im Ereignisfall ab?

Disaster Recovery läuft im Ereignisfall in einer festen Abfolge ab, die vor dem Ereignis festgelegt und geübt werden muss. Improvisation kostet in den ersten Stunden die Zeit, die später für die Wiederherstellung fehlt.

Erkennung und Bewertung
Monitoring, Service Desk oder ein Sicherheitsvorfall melden eine Störung. Zu klären ist, ob es sich um einen behebbaren Vorfall oder um einen Ausfall handelt, der eine Ausweichlösung erfordert.
Erklärung des Notfalls (Disaster Declaration)
Eine benannte Rolle erklärt den Notfall formell und löst damit den Plan aus. Diese Befugnis muss eindeutig geregelt sein, einschließlich der Vertretung außerhalb der Dienstzeiten – in der Praxis vergeht hier häufig die meiste Zeit.
Aktivierung von Teams und Kommunikation
Wiederherstellungsteams, Krisenstab und relevante Dienstleister werden alarmiert. Parallel dazu wird ein Kommunikationskanal etabliert, der von der ausgefallenen Infrastruktur unabhängig ist.
Failover und priorisierter Wiederanlauf
Die Umschaltung auf die Ausweichumgebung folgt der dokumentierten Abhängigkeitsreihenfolge: zuerst Netz, Namensauflösung und Verzeichnisdienste, dann Datenbanken, dann Anwendungen und Schnittstellen. Wer diese Reihenfolge im Ereignisfall erst ermittelt, verliert Stunden.
Verifikation und Freigabe
Vor der Rückgabe an die Fachbereiche werden Datenintegrität, Vollständigkeit und Funktionsfähigkeit anhand definierter Kriterien geprüft – einschließlich der Prüfung auf Schadcode und persistente Zugänge bei Sicherheitsvorfällen.
Failback in den Normalbetrieb
Die Rückführung in die primäre Umgebung wird eigenständig geplant, mit erneutem Datenabgleich und einem eigenen Wartungsfenster. Sie ist häufig anspruchsvoller als der Failover, weil zwei Datenstände zusammengeführt werden müssen.
Nachbereitung
Auswertung der erreichten Werte (RTA/RPA), Lessons Learned, Planpflege und Dokumentation für Aufsicht, Versicherer und interne Revision.

Wie verändert Ransomware das Disaster Recovery?

Ransomware verändert Disaster Recovery grundlegend, weil der Ausfall hier nicht zufällig, sondern gezielt und gegen die Wiederherstellung gerichtet ist. Angreifer suchen vor der Verschlüsselung systematisch Backup-Systeme, Sicherungsserver und Snapshots und versuchen, sie zu löschen oder mitzuverschlüsseln. Klassische Konzepte, die auf einen technischen Defekt hin entworfen wurden, greifen in diesem Szenario zu kurz.

Drei Konsequenzen sind wesentlich:

Erstens muss mindestens eine Sicherung außerhalb der Reichweite kompromittierter Konten liegen – offline, unveränderlich oder in einer separaten Administrationsdomäne, ausdrücklich nicht mit den Anmeldedaten der Produktivumgebung erreichbar.

Zweitens verschiebt sich der Recovery Point: Relevant ist nicht die letzte Sicherung, sondern die letzte nachweislich unbelastete, was einen größeren Datenverlust bedeuten kann als geplant.

Drittens ist eine Wiederherstellung in einer noch kompromittierten Umgebung wertlos; deshalb arbeiten Organisationen mit isolierten Wiederherstellungsumgebungen (Clean Room Recovery).

Besondere Aufmerksamkeit verdient das zentrale Verzeichnis. Ist Active Directory betroffen, hängt praktisch jede Anmeldung an einem System, das selbst wiederhergestellt werden muss – nach einem eigenen, dokumentierten Verfahren zur Forest Recovery.

Erfahrungsgemäß sind Wiederherstellungspläne genau hier am häufigsten unvollständig: Die Anwendungen sind beschrieben, die Voraussetzung für ihre Nutzung nicht. Hinzu kommt die Spannung zwischen Forensik und Eile, weil ein zu schnelles Überschreiben kompromittierter Systeme Beweise zerstört, die für Meldepflichten und Versicherungsfälle gebraucht werden. Architekturansätze wie Zero Trust begrenzen die Ausbreitung im Vorfeld, ersetzen aber keine Wiederherstellungsfähigkeit.

Wie wird ein Disaster-Recovery-Plan getestet?

Ein Disaster-Recovery-Plan wird in gestufter Tiefe getestet, weil unterschiedliche Testarten unterschiedliche Fehlerklassen aufdecken. Der Plan-Review prüft Aktualität und Vollständigkeit der Dokumentation, die Tabletop-Übung die Rollen und Entscheidungswege im Trockenlauf, der Restore-Test die tatsächliche Wiederherstellbarkeit einzelner Systeme, der Failover-Test die Umschaltung ganzer Umgebungen und die Vollübung schließlich den Ablauf unter realistischen Bedingungen. Erst die höheren Stufen liefern belastbare Aussagen über RTA und RPA.

Ein regelmäßiger Wiederherstellungstest ist kein optionaler Reifegrad, sondern wird in vielen Regelwerken gefordert. Als Mindestrhythmus hat sich ein jährlicher Test kritischer Systeme etabliert, ergänzt um anlassbezogene Tests nach wesentlichen Änderungen an Architektur, Dienstleistern oder Datenmengen.

Aussagekräftig sind Tests jedoch nur, wenn sie die unbeliebten Bedingungen einschließen: ohne die üblichen Administratoren, ohne Zugriff auf die Dokumentation im Primärsystem, mit der vollen Datenmenge. Erfahrungsgemäß scheitern Wiederherstellungen selten am Verfahren, sondern an Details – fehlenden Lizenzschlüsseln, abgelaufenen Zertifikaten, nicht dokumentierten Konfigurationen und längeren Übertragungszeiten als kalkuliert.

Welche Normen und Standards gelten für Disaster Recovery?

Für Disaster Recovery sind mehrere Regelwerke maßgeblich, die einander ergänzen. ISO/IEC 27031 ist der zentrale Leitfaden für die IKT-Bereitschaft zur Aufrechterhaltung des Geschäftsbetriebs (ICT Readiness for Business Continuity, IRBC) und verbindet technische Wiederherstellung mit den Anforderungen des Kontinuitätsmanagements nach ISO 22301.

ISO/IEC 27001 adressiert das Thema in der Fassung von 2022 über die Maßnahmen A.5.29 (Informationssicherheit bei Störungen), A.5.30 (IKT-Bereitschaft für Business Continuity) und A.8.13 (Informationssicherung).

Im deutschsprachigen Raum sind die Werke des BSI die praktische Referenz. Der BSI-Standard 200-4 ordnet Wiederanlauf und Wiederherstellung in den Kontinuitätsprozess ein und unterscheidet ausdrücklich zwischen Notbetrieb und Rückkehr zum Normalbetrieb.

Das IT-Grundschutz-Kompendium konkretisiert die technische Seite, insbesondere die Bausteine CON.3 Datensicherungskonzept und DER.4 Notfallmanagement.

Im internationalen Kontext ist NIST SP 800-34 (Contingency Planning Guide) verbreitet, das die Planungssystematik von der Business Impact Analyse bis zum Testprogramm beschreibt; für IT-Service-Continuity-Prozesse liefert ITIL den Rahmen.

Welche gesetzlichen Anforderungen an Disaster Recovery gelten?

Disaster Recovery ist für viele Organisationen keine freiwillige Vorsorge, sondern rechtliche Pflicht.

Die NIS-2-Richtlinie (EU) 2022/2555 verlangt in Artikel 21 Risikomanagementmaßnahmen, die Backup-Management, Wiederherstellung nach einem Notfall und Krisenmanagement ausdrücklich einschließen; betroffen sind wesentliche und wichtige Einrichtungen in einem breiten Spektrum von Sektoren. Die Umsetzung in nationales Recht erfolgt in Deutschland über das NIS-2-Umsetzungsgesetz, dessen aktueller Stand und Fristen vor einer Veröffentlichung geprüft werden sollten.

Im Finanzsektor gilt die DORA-Verordnung (EU) 2022/2554. Sie fordert eine IKT-Geschäftsfortführungspolitik einschließlich Reaktions- und Wiederherstellungsplänen (Artikel 11) sowie explizite Backup-, Wiedergewinnungs- und Wiederherstellungsverfahren mit getrennten Umgebungen (Artikel 12) und verpflichtet zu einem dokumentierten Testprogramm. Ergänzend wirken die aufsichtlichen Anforderungen in MaRisk sowie BAIT, VAIT und KAIT.

Für Betreiber kritischer Infrastrukturen ergeben sich Pflichten aus der KRITIS-Regulierung und dem BSI-Gesetz, das Vorkehrungen zur Vermeidung von Störungen der Verfügbarkeit nach dem Stand der Technik verlangt.

Datenschutzrechtlich ist Artikel 32 DSGVO einschlägig: Absatz 1 nennt die Verfügbarkeit als Schutzziel und fordert in Buchstabe c ausdrücklich die Fähigkeit, die Verfügbarkeit personenbezogener Daten und den Zugang zu ihnen bei einem physischen oder technischen Zwischenfall rasch wiederherzustellen. Damit ist ein funktionierendes Wiederherstellungsverfahren Bestandteil der DSGVO-Konformität und nicht nur eine Frage der IT-Betriebsqualität.

Was ist Disaster Recovery as a Service (DRaaS)?

Disaster Recovery as a Service (DRaaS) ist die Auslagerung von Wiederherstellungskapazitäten an einen Dienstleister, der Zielinfrastruktur, Replikation und Failover-Prozesse als Dienst bereitstellt. Für Organisationen ohne zweites Rechenzentrum senkt DRaaS die Einstiegshürde erheblich, weil Standby-Kapazität nicht dauerhaft vorgehalten und finanziert werden muss.

Verantwortung lässt sich damit allerdings nicht auslagern. Zu klären bleiben die vertraglich zugesicherten RTO- und RPO-Werte samt Nachweis, das Verhalten bei einem regionalen Großereignis mit vielen gleichzeitig betroffenen Kunden, die Rechte zur eigenständigen Durchführung von Tests, Datenhaltung und Verarbeitungsort sowie die Rückführung zum eigenen Betrieb oder zu einem anderen Anbieter. Aufsichtsrechtlich gelten solche Anbieter regelmäßig als kritische IKT-Drittdienstleister mit entsprechenden Anforderungen an Vertragsgestaltung und Ausstiegsstrategie. Für kleinere Organisationen gilt zudem dasselbe wie im Kontinuitätsmanagement: Ein schlankes Verfahren mit geprüften Backups, dokumentierter Wiederanlaufreihenfolge und jährlichem Restore-Test ist wirksamer als eine ambitionierte Architektur, die nie fertig wird.

Welche Rolle spielt Kommunikation im Disaster Recovery?

Kommunikation ist im Disaster Recovery eine kritische Ressource und im Ereignisfall auffallend häufig selbst betroffen. Ist die Primärinfrastruktur ausgefallen oder kompromittiert, sind E-Mail, Telefonanlage, Chat-Plattform und Intranet oft Teil des Schadens. Genau dann müssen Wiederherstellungsteams koordiniert, Entscheidungen weitergegeben, Dienstleister eingebunden und Meldefristen eingehalten werden. Ein Plan, dessen Alarmierung auf dem ausgefallenen System basiert, ist im Ernstfall nicht auslösbar.

Aus Sicht des Disaster Recovery sind drei Anforderungen entscheidend:

Unabhängigkeit vom Schadensbild: Kontaktdaten, Eskalationswege und Planunterlagen müssen ohne die betroffene Umgebung erreichbar sein.
Trennung der Kommunikationskreise: Technische Wiederherstellungsteams, Entscheidungsebene und Gesamtorganisation benötigen getrennte, klar zugeordnete Kanäle, damit Statusmeldungen nicht im allgemeinen Informationsfluss untergehen.
Nachvollziehbarkeit: Meldungen, Freigaben und Entscheidungen während der Wiederherstellung sind später Nachweisgrundlage gegenüber Aufsicht, Versicherern und Revision.

Fehlen freigegebene und geübte Alternativkanäle, weichen Beteiligte erfahrungsgemäß auf private Consumer-Messenger aus. Es entsteht eine Schatten-IT genau in dem Moment, in dem Vertraulichkeit und Beweisfähigkeit besonders wichtig sind – mit Folgen für Datenschutz und Dokumentation.

Organisationen erfüllen diese Anforderung in der Regel durch vorab bereitgestellte, von der Primärinfrastruktur unabhängige Kommunikationslösungen, deren Verfügbarkeit in den Disaster-Recovery-Tests überprüft wird und die Teil der Notfallkommunikation sind.

Wie sich sichere Kommunikation für Wiederherstellungsteams und Krisenstab abbilden lässt, zeigt Teamwire in einer Demo oder im kostenlosen Test.

Welche Fehler treten bei Disaster Recovery häufig auf?

Der häufigste Fehler im Disaster Recovery ist die Verwechslung von Datensicherung und Wiederherstellungsfähigkeit: Backups laufen, werden jedoch nie vollständig wiederhergestellt. Weitere typische Schwachstellen aus der Praxis:

Backups liegen in derselben Domäne und im selben Netzsegment wie die Produktivsysteme und sind mit kompromittierten Administratorkonten löschbar
Wiederherstellungspläne und Notfallkontakte existieren ausschließlich digital in dem System, das ausgefallen ist
Zielwerte für RTO und RPO sind gesetzt, ohne dass Maßnahmen, Bandbreiten und Kapazitäten sie tragen
die Abhängigkeitsreihenfolge des Wiederanlaufs ist nicht dokumentiert, insbesondere für Verzeichnisdienste, Namensauflösung und Zertifikatsinfrastruktur
Tests beschränken sich auf einzelne Dateien oder virtuelle Maschinen statt auf zusammenhängende Anwendungsketten
der Failback in den Normalbetrieb ist ungeplant, obwohl er zwei Datenstände zusammenführen muss
Kommunikation und Alarmierung werden als selbstverständlich vorausgesetzt statt als eigene, unabhängig geplante Ressource

Zusammenfassung: Wichtige Punkte zu Disaster Recovery

Disaster Recovery (DR) ist die geplante technische Wiederherstellung von IT-Systemen, Anwendungen und Daten nach einem schwerwiegenden Ausfall.
Disaster Recovery ist die Umsetzungsebene innerhalb des IT-Service-Continuity-Managements; die fachlichen Zeitvorgaben kommen aus dem Business Continuity Management.
RTO und RPO sind die bestimmenden Kennzahlen: Sie legen die zulässige Ausfallzeit und den zulässigen Datenverlust fest und dimensionieren damit die gesamte Architektur.
Backup ist Voraussetzung, nicht Ersatz: Erst ein geprüftes Wiederherstellungsverfahren mit Zielumgebung und Wiederanlaufreihenfolge ergibt Disaster Recovery.
Die Strategiepalette reicht von Backup & Restore über Pilot Light und Warm Standby bis Active-Active – mit RTO von Tagen bis Sekunden und entsprechend steigenden Kosten.
Bei Ransomware zählt nicht die letzte, sondern die letzte nachweislich unbelastete Sicherung; unveränderliche oder offline gehaltene Backups und isolierte Wiederherstellungsumgebungen sind entscheidend.
Maßgebliche Regelwerke sind ISO/IEC 27031, ISO 22301, ISO/IEC 27001, der BSI-Standard 200-4 und NIST SP 800-34; für Georedundanz empfiehlt das BSI Standortabstände von mindestens 200 Kilometern.
NIS2, DORA, die KRITIS-Regulierung und Artikel 32 DSGVO machen Wiederherstellungsfähigkeit zur rechtlichen Pflicht – einschließlich Nachweis regelmäßiger Tests.
Ein Disaster-Recovery-Plan ist nur so gut wie sein letzter Wiederherstellungstest; belastbar sind allein die gemessenen Istwerte (RTA/RPA), nicht die Zielwerte.
Kommunikation ist eine kritische Ressource: Alarmierung, Teamkoordination und Meldepflichten brauchen Kanäle, die vom ausgefallenen System unabhängig sind.