Disaster Recovery Test: den Wiederanlauf belegen statt hoffen
Disaster Recovery Test: was ein grünes Backup nicht belegt
Laut TÜV Cybersecurity Studie 2025 haben nur 22 Prozent der Unternehmen in Deutschland in den zurückliegenden zwei Jahren eine Notfallübung durchgeführt. Geprobt wird damit selten, was Disaster Recovery meint, die Rückkehr zum geordneten Betrieb nach einem schweren IT-Ausfall.
Ein Disaster Recovery Test, kurz DR-Test, ist die geplante Probe, bei der eine Organisation ihre Anwendungen aus Sicherungen oder auf Ersatzsystemen wiederherstellt. Gemessen wird, ob der Betrieb innerhalb der zugesagten Wiederanlaufzeit (RTO) und mit höchstens dem zulässigen Datenverlust (RPO) zurückkehrt. Bestanden ist der Test erst, wenn die Fachabteilung mit der wiederhergestellten Anwendung arbeiten kann, nicht schon, wenn die Daten zurückkopiert sind.
Was die Sicherungssoftware meldet und was nicht
Die Meldung „Sicherung erfolgreich“ bestätigt einen Kopiervorgang. Ob die Kopie vollständig ist und ob die Anwendung mit ihr startet, prüft sie nicht. Das laufende Backup Monitoring erkennt abgebrochene Läufe, eine Rückspielung ersetzt es nicht. Zwischen Sicherung und arbeitsfähigem Betrieb liegen Schritte, die nur ein Test zeigt. Server werden neu aufgesetzt, Datenbank und Dateiablage auf denselben Stand gebracht und Schnittstellen wieder verbunden.
Was § 30 BSIG dazu verlangt
Für besonders wichtige Einrichtungen ist der Unterschied keine Stilfrage. § 30 Abs. 2 Nr. 3 BSIG verlangt die Aufrechterhaltung des Betriebs mit Backup-Management und Wiederherstellung nach einem Notfall, Nr. 6 zusätzlich Verfahren, mit denen die Wirksamkeit solcher Maßnahmen bewertet wird. Der Test der Wiederherstellung nach einem Notfall liefert für beide Punkte den Beleg, den eine Datensicherung für Unternehmen und Behörden allein nicht erbringt.
Woran zeigt sich, dass der Test bestanden ist?
Ob ein Test bestanden ist, wird vor seinem Beginn festgelegt und nicht danach. Sonst passt sich das Kriterium dem Ergebnis an, und der Bericht belegt nichts. Vier Messpunkte gehören in jede Planung:
- Zeit bis zur arbeitsfähigen Anwendung, verglichen mit dem RTO
- Datenstand nach der Rückspielung, verglichen mit dem RPO
- fachliche Prüfung mit echten Vorgängen durch die Fachabteilung
- Anmeldung, Rechte und Schnittstellen vollständig vorhanden
Welche Wiederanlaufzeit die Messung erreichen muss, steht im IT Service Level Agreement mit dem Betriebsdienstleister oder in der internen Vorgabe der Einrichtung. Fehlt dort ein Wert, fehlt dem Test der Maßstab. Wiederanlaufziele testen setzt also voraus, dass sie zuvor schriftlich vereinbart wurden. Ein verfehlter Messpunkt ist kein Anlass, so lange zu wiederholen, bis das Ergebnis passt, denn aus dem Protokoll eines verfehlten Tests entsteht die eigentlich wertvolle Information.
Wiederherstellbarkeit messen statt annehmen
Ein Disaster Recovery Test beginnt mit der Auswahl der Anwendung, legt dann die Testtiefe fest und klärt, ob in einer Testumgebung oder im Betrieb geprüft wird. Die Tiefe reicht von der Tabletop Übung am Tisch bis zur echten Umschaltung auf Ersatzsysteme. Messbar wird die Wiederherstellbarkeit immer nur für eine konkrete Anwendung, nie für die IT im Ganzen.
Welche Anwendung in den ersten Test gehört
Den Anfang macht die Anwendung mit der kürzesten zulässigen Ausfallzeit. Diese Zeit steht in der Business Impact Analyse, also der Aufstellung, wie lange ein Geschäftsprozess ohne seine IT auskommt. Meist ist das ein Fachverfahren, ohne das Aufträge oder Einsätze stillstehen. Mit einer einzigen Anwendung zu beginnen, macht das Ergebnis messbar, weil sonst offen bleibt, welches System die Zeit gekostet hat.
Zu den Disaster Recovery Test Best Practices gehört ein schriftlicher Ablauf, der vor dem ersten Handgriff steht. Ein Disaster Recovery Test Plan legt mindestens fest:
- getestete Anwendung und Szenario
- Erfolgskriterien für RTO und RPO
- Beteiligte und Entscheidungsbefugnis
- Abbruchkriterium und Weg zurück
- Umgebung und Zeitfenster
- Art der Dokumentation
Testumgebung oder laufender Betrieb
Der erste Test läuft in einer getrennten Umgebung, damit ein Fehler den Betrieb nicht trifft. Sie belegt die technische Wiederherstellbarkeit, aber nicht, ob Leitungen und Kapazität im Ernstfall tragen. Für Anwendungen mit sehr kurzer Wiederanlaufzeit gehört deshalb ein geplanter Test im Betrieb dazu, angekündigt, in einem Wartungsfenster und mit dem Weg zurück aus dem Disaster Recovery Test Plan. Chaos Engineering geht weiter und löst solche Ausfälle regelmäßig gezielt aus.
Was unterscheidet Failover Test und Rückspielung?
Beim Failover Test übernimmt ein bereitstehendes Ersatzsystem die Arbeit, meist in einem zweiten Rechenzentrum. Geprüft wird die Umschaltung, also ob Datenabgleich und Anmeldung auf der Gegenseite funktionieren. Die Rückspielung aus dem Backup beginnt dagegen bei null, mit neu aufgesetzten Servern und eingespielter Sicherung. Ein bestandener Failover Test belegt nicht, dass die Sicherung brauchbar ist. Denn ein Angriff auf das Hauptsystem erreicht über die Spiegelung oft auch das Ersatzsystem.
Vier Stufen der Testtiefe
Welche Stufen der Wiederherstellung zur Wahl stehen, vom kalten Ersatzsystem bis zur ständig mitlaufenden Kopie, legt das Konzept der Disaster Recovery fest. Daran hängt, welcher Test möglich ist. Die Disaster Recovery Test Methoden unterscheiden sich vor allem in ihrer Tiefe, und die Tabelle ordnet die vier Stufen nach dem, was sie prüfen:
| Testtiefe | prüft | Aufwand |
|---|---|---|
| Plan-Review | Vollständigkeit, Zuständigkeiten | gering |
| Teilrückspielung | Daten und Laufzeit | mittel |
| Failover Test | Umschaltung | hoch |
| Volltest | Gesamtbetrieb | sehr hoch |
Eine Tabletop Übung gehört zur ersten Stufe, dabei sprechen die Beteiligten ein Szenario am Tisch durch. Eine Krisenübung setzt eine Ebene höher an und prüft Meldewege und Entscheidungen. Beide ersetzen keinen Recovery Test, sie bereiten ihn vor.
Disaster Recovery Test nach einem Ransomware-Angriff
Nach einem Ransomware-Angriff reicht die jüngste Sicherung oft nicht, weil sie die Zugänge der Angreifer bereits enthalten kann. Ein Disaster Recovery Test für diesen Fall prüft deshalb zwei zusätzliche Dinge. Er sucht den letzten sauberen Stand, und er prüft, was die Anwendung braucht und in keiner ihrer Sicherungen steckt.
Den letzten sauberen Stand finden
Angreifer können sich vor der Verschlüsselung Tage oder Wochen unbemerkt im Netz aufhalten. Die Sicherungen aus dieser Zeit enthalten ihre Zugänge und manchmal ihre Werkzeuge. Ransomware Recovery beginnt deshalb mit der Frage, bis zu welchem Tag zurückgegangen werden muss. Jeder Tag, den der saubere Stand zurückliegt, kostet Daten über dem RPO. Den Tag bestimmt die Auswertung des Angriffs, nicht die Sicherungssoftware.
Cyber Recovery aus der isolierten Kopie
Cyber Recovery bezeichnet die Wiederherstellung aus einer isolierten Kopie, auf die aus dem Netz kein Zugriff besteht. Unveränderbare Sicherungen, wie sie aktuelle Backup-Lösungen anbieten, sind dafür die Voraussetzung. Um die Wiederherstellung nach Ransomware testen zu können, wird eine solche Kopie in eine abgeschottete Umgebung eingespielt, auf Schadsoftware geprüft und erst dann gestartet. Die Dauer dieser Prüfung gehört in die gemessene Zeit, auch wenn ein Wiederherstellungsplan sie nicht vorsieht, der nur mit Hardwareausfällen rechnet.
Was kein Backup zurückbringt
Eine Anwendung läuft nicht allein aus ihren Daten. Sie braucht Dienste, die außerhalb ihrer Sicherung liegen und nach einem Angriff oft selbst betroffen sind.
❗ Verzeichnisdienst mit Benutzerkonten und Rechten
❗ Schlüssel und Zertifikate verschlüsselter Daten
❗ Zugangsdaten zu Schnittstellenpartnern
❗ Lizenzserver und Aktivierungen
❗ DNS-Einträge und Firewallregeln
Fehlt einer dieser Punkte, startet die Anwendung aus einer tadellosen Sicherung und ist trotzdem nicht nutzbar. Selbst eine konsistente Datenbanksicherung bringt nur den Datenbestand zurück, nicht die Anmeldung, über die die Fachabteilung ihn erreicht. Ein Ransomware Recovery Test, der diese Dienste auslässt, misst deshalb eine Zeit, die im Ernstfall nicht erreicht wird.
Nach dem Test: Befund, Maßnahmen und Rhythmus
Ein Disaster Recovery Test ist erst mit seiner Auswertung abgeschlossen. Aus dem Protokoll entstehen Befunde, aus den Befunden ein Maßnahmenplan mit Fristen, und aus der Wiederanlaufzeit der Anwendung ergibt sich, wann der nächste Test fällig ist. Belastbar wird der Nachweis der Wiederherstellbarkeit durch diese Folge aus Test, Befund und Korrektur, nicht durch einen einzelnen fehlerfreien Lauf.
Aus dem Protokoll wird ein Maßnahmenplan
Ein Test, der eine Lücke findet, hat seinen Zweck erfüllt. Der Übungsbaukasten des UP KRITIS, eine Vorlage für Notfallübungen, sieht nach jeder Durchführung eine Auswertung der Protokolle vor. Daraus entsteht ein Maßnahmenplan mit verantwortlicher Person und Frist je Verbesserung, und erkannte Risiken gehen an das Risikomanagement. Der Disaster Recovery Test Report hält dafür die Soll- und Istwerte nebeneinander fest. Eine verfehlte Wiederanlaufzeit steht im Report als Zahl, nicht als Eindruck.
Welcher Rhythmus passt zu vier Stunden Wiederanlauf?
Der Rhythmus folgt der Wiederanlaufzeit, nicht dem Kalender. Der Übungsbaukasten nennt als Beispiel eine Richtlinie, nach der Anwendungen mit einer Wiederanlaufzeit bis vier Stunden mindestens alle zwei Jahre getestet werden und Anwendungen bis zu einem Tag mindestens alle drei Jahre. Ein festes Intervall schreibt das BSIG nicht vor. Der Takt ist eine eigene Festlegung der Einrichtung und muss begründet sein. Wiederanlaufziele testen heißt deshalb auch, den Test der Disaster Recovery nach einer großen Änderung an der Architektur nicht bis zum nächsten Termin aufzuschieben.
Failover Test mit dem Betriebsdienstleister planen
Betreibt ein Dienstleister die Anwendung, gehört er an den Tisch, denn er kennt die Datenbank und die Schnittstellen im Detail. Den Ernstfall mit dem IT-Dienstleister üben heißt, Zeitfenster, Rollen und Rückweg gemeinsam festzulegen, bevor ein Failover Test beginnt. Die Verantwortung bleibt dabei bei der Einrichtung, denn die Nachweis- und Dokumentationspflichten der IT-Compliance lassen sich nicht auslagern.
