Disaster-Recovery-Test im Unternehmen durchführen

Ein Disaster-Recovery-Test im Unternehmen durchführen heißt, die tatsächliche Wiederanlauffähigkeit kritischer IT-Services unter nachvollziehbaren Bedingungen zu überprüfen. Entscheidend ist nicht, ob ein Notfallhandbuch vollständig wirkt. Entscheidend ist, ob Anwendungen, Daten, Infrastruktur und Verantwortliche innerhalb der vereinbarten Zeit wieder arbeitsfähig sind - und ob die Fachbereiche ihre kritischen Prozesse fortsetzen können.

Ein solcher Test ist damit ein zentraler Baustein des IT Service Continuity Managements (ITSCM). Er schafft belastbare Nachweise für Geschäftsführung, Revision, Kunden und Aufsichtsstellen. Gleichzeitig deckt er Abhängigkeiten auf, die in Architekturdiagrammen und Notfallplänen häufig nicht sichtbar sind: fehlende Berechtigungen, nicht erreichbare Dienstleister, unvollständige Runbooks oder zu optimistisch angesetzte Wiederherstellungszeiten.

Was ein Disaster-Recovery-Test leisten muss

Disaster Recovery bezeichnet die technische und organisatorische Wiederherstellung von IT-Services nach einem schwerwiegenden Ausfall. Im Zentrum stehen etwa Rechenzentrumsstörungen, Ransomware, Ausfälle von Cloud-Diensten, beschädigte Datenbanken oder der Verlust wesentlicher Netzwerkkomponenten. Ein Disaster-Recovery-Test prüft, ob die dafür vorgesehenen Maßnahmen unter realistischen Annahmen funktionieren.

Dabei genügt es nicht, einzelne Backups erfolgreich zurückzuspielen. Ein Backup ist nur eine Voraussetzung. Der Nachweis gelingt erst, wenn die wiederhergestellten Daten konsistent sind, die Anwendung startet, Schnittstellen erreichbar sind, Benutzer arbeiten können und die vereinbarten Serviceziele eingehalten werden. Bei geschäftskritischen Systemen muss zudem geprüft werden, ob die fachliche Verarbeitung korrekt fortgesetzt werden kann.

DR-Tests sind klar vom umfassenderen Business Continuity Management abzugrenzen. BCM sichert die Fortführung kritischer Geschäftsprozesse auch bei personellen, räumlichen oder Lieferkettenbedingten Störungen. ITSCM betrachtet insbesondere die Wiederherstellung der benötigten IT-Services. Krisenmanagement wiederum stellt sicher, dass Entscheidungen, Kommunikation und Eskalation im Ausnahmefall funktionieren. In der Praxis greifen alle drei Disziplinen ineinander.

Vor dem Disaster-Recovery-Test: Ziele und Umfang festlegen

Ein Test beginnt nicht mit dem technischen Umschalten, sondern mit einer präzisen Zielsetzung. Welche Services sollen wiederhergestellt werden? Welches Schadensszenario wird angenommen? Welche Nachweise erwartet das Management, die Revision oder eine regulierte Stelle? Ohne diesen Rahmen wird aus einer Übung schnell ein schwer vergleichbarer Techniktest.

Grundlage sind die Ergebnisse der Business Impact Analysis und der Risikoanalyse. Daraus ergeben sich die priorisierten Prozesse sowie die unterstützenden Anwendungen, Infrastrukturkomponenten, Daten und Dienstleister. Für jeden relevanten Service sollten der Recovery Time Objective (RTO), also die maximal akzeptierte Wiederherstellungszeit, und der Recovery Point Objective (RPO), also der maximal tolerierbare Datenverlust, verbindlich festgelegt sein.

Die Planung muss Abhängigkeiten ausdrücklich berücksichtigen. Eine Fachanwendung kann technisch bereitstehen und dennoch nicht nutzbar sein, wenn Identitätsmanagement, DNS, Netzwerksegmentierung, Zertifikate, Batch-Verarbeitung oder externe Schnittstellen fehlen. Gerade hybride Architekturen mit On-Premises-Systemen, Cloud-Plattformen und SaaS-Angeboten verlangen eine durchgängige Betrachtung der Servicekette.

Für den Testauftrag sollten mindestens vier Punkte dokumentiert werden:

• das Szenario und die klaren Annahmen zum Schadensereignis,
• die im Scope befindlichen Services, Standorte, Daten und Dienstleister,
• messbare Erfolgskriterien einschließlich RTO, RPO und fachlicher Abnahme,
• Rollen, Entscheidungsbefugnisse, Kommunikationswege und Abbruchkriterien.

Abbruchkriterien sind kein Zeichen mangelnder Ambition. Sie schützen den laufenden Betrieb, falls sich während eines produktionsnahen Tests Risiken ergeben, die nicht mehr vertretbar sind. Besonders bei KRITIS-nahen Umgebungen, hochverfügbaren Produktionssystemen oder zeitkritischen Transaktionsdiensten ist diese Absicherung unverzichtbar.

Das passende Testszenario auswählen

Nicht jeder Test muss sofort einen vollständigen Ausfall simulieren. Der angemessene Testgrad hängt von Kritikalität, Veränderungsdynamik, Architektur und akzeptiertem Betriebsrisiko ab. Ein Tabletop-Test kann Verantwortlichkeiten und Entscheidungswege prüfen. Ein technischer Wiederherstellungstest validiert beispielsweise Backup, Infrastruktur-as-Code oder Datenbank-Recovery. Ein Failover-Test überprüft die Umschaltung auf einen Ausweichstandort oder eine alternative Cloud-Region.

Die höchste Aussagekraft liefert meist ein integrierter End-to-End-Test: Ein priorisierter Service wird anhand eines realistischen Szenarios wiederhergestellt und durch den Fachbereich abgenommen. Dieser Ansatz erzeugt Aufwand und benötigt sorgfältige Koordination, weil er Betrieb, Informationssicherheit, Fachbereiche und externe Partner einbindet. Dafür beantwortet er die Frage, die für die Unternehmensresilienz zählt: Kann der kritische Prozess innerhalb der geforderten Zeit tatsächlich weiterlaufen?

Die Szenarien sollten nicht bei einem generischen Serverausfall stehen bleiben. Sinnvoll sind Varianten, die reale Schwachstellen adressieren: Verschlüsselung produktiver Daten, kompromittierte Administrationskonten, Verlust einer Cloud-Region, beschädigte Konfigurationsdaten oder ein gleichzeitiger Ausfall eines zentralen Dienstleisters. Bei Cyberangriffen ist zusätzlich zu prüfen, ob Recovery-Umgebungen und Backups frei von Schadsoftware sind. Eine schnelle Wiederherstellung in eine kompromittierte Umgebung löst das Problem nicht.

Durchführung: Zeit messen, Entscheidungen sichtbar machen

Am Testtag braucht es eine klare Taktung. Ein Testleiter steuert Ablauf, Dokumentation und Eskalationen. Technische Teams führen Runbooks aus, während Service Owner und Fachverantwortliche die Wiederherstellung gegen die definierten Kriterien prüfen. Die Geschäfts- oder Krisenorganisation muss je nach Szenario Entscheidungen treffen, etwa zur Priorisierung konkurrierender Services oder zur Freigabe eines Notbetriebs.

Gemessen werden sollte nicht nur die Zeit bis zum ersten gestarteten Server. Relevant sind der Beginn der Störungserkennung, die Alarmierung, die Entscheidung zur Aktivierung, der Start der Wiederherstellung, die technische Verfügbarkeit, die fachliche Nutzbarkeit und die formale Abnahme. So lässt sich nachvollziehen, an welcher Stelle Zeit verloren geht. Häufig liegt die Verzögerung nicht im Restore selbst, sondern in unklaren Zuständigkeiten, fehlenden Zugängen oder ungeprüften Freigabeprozessen.

Ein belastbarer Test dokumentiert auch Abweichungen. Wenn der RTO verfehlt wurde, ist die Ursache zu benennen: War die Zielzeit unrealistisch, fehlte Infrastrukturkapazität, war die Datenmenge höher als erwartet oder verlief die Abstimmung mit einem Provider zu langsam? Nur konkrete Ursachen ermöglichen wirksame Maßnahmen.

Testergebnisse in ITSCM und BCM überführen

Der eigentliche Nutzen entsteht nach dem Test. Ergebnisse müssen bewertet, priorisiert und in einen Maßnahmenplan überführt werden. Kritische Feststellungen brauchen Verantwortliche, Fristen, Budgetentscheidungen und eine überprüfbare Wirksamkeitskontrolle. Ein offener Punkt in einem Testprotokoll ist noch keine Risikoreduktion.

Typische Maßnahmen reichen von der Anpassung von Runbooks und Kontaktlisten über zusätzliche Wiederherstellungskapazitäten bis zur Härtung von Backup-Konzepten und der Korrektur von Service-Abhängigkeiten. Auch Vertrags- und Lieferantenmanagement können betroffen sein, wenn zugesicherte Wiederanlaufleistungen nicht nachweisbar erbracht werden. Änderungen an Architektur, Anwendungen oder Betriebsmodellen müssen anschließend in die Notfallplanung zurückfließen.

Für NIS-2, DORA, KRITIS-Anforderungen oder eine Orientierung am BSI-Standard 200-4 ist diese Nachweisführung besonders relevant. Gefordert ist nicht allein vorhandene Dokumentation, sondern ein gelebter, wiederkehrender Prozess aus Planung, Übung, Bewertung und Verbesserung. Die Testfrequenz sollte sich daher an Kritikalität und Veränderungsrate orientieren. Ein jährlich getestetes Verfahren kann bei monatlichen Architekturänderungen zu selten sein. Umgekehrt ist ein aufwendiger Volltest für jeden weniger kritischen Service nicht immer wirtschaftlich.

Eine zentrale Softwareplattform kann die Pflege deutlich erleichtern: Sie verbindet Business-Impact-Analysen, Service-Abhängigkeiten, Notfallpläne, Maßnahmen und Testnachweise. Mit [alive-IT] lassen sich diese Informationen konsolidieren und für Audits, Übungen sowie operative Wiederanlaufentscheidungen verfügbar halten. Der Nutzen liegt nicht allein in der Dokumentation, sondern in ihrer kontrollierten Aktualität.

Häufige Fehler bei Disaster-Recovery-Tests

Der verbreitetste Fehler ist ein Test ohne fachliche Abnahme. Ein grüner Status in der Infrastruktur sagt nichts darüber aus, ob Buchungen verarbeitet, Aufträge disponiert oder Kundenanfragen bearbeitet werden können. Ebenso problematisch sind Tests mit vollständig vorbereiteten Teams, bei denen jede Person den Ablauf bereits kennt. Sie bestätigen dann vor allem bekannte Routinen, nicht die Handlungsfähigkeit unter Störung.

Auch unklare Eigentümerschaft schwächt die Aussagekraft. IT kann die technische Wiederherstellung koordinieren, aber die Priorität eines Geschäftsprozesses und die Akzeptanz eines Notbetriebs müssen gemeinsam mit den Fachbereichen entschieden werden. Ein Disaster-Recovery-Test ist deshalb keine isolierte Aufgabe des Infrastrukturteams.

Wirkungsvolle Tests schaffen Transparenz, ohne den Betrieb unnötig zu gefährden. Wer mit einem klaren Scope beginnt, realistische Szenarien schrittweise steigert und Erkenntnisse konsequent nachverfolgt, entwickelt aus jeder Übung mehr als einen Prüfbericht: eine belastbarere Entscheidungs- und Wiederanlauffähigkeit für den Ernstfall.