Checkliste IT-Notfalltest (Disaster Recovery)
Checkliste IT-Notfalltest für den Disaster-Recovery-Plan: Szenario, Failover oder Neuaufbau, RTO und RPO messen, Rückschwenk und Folgeaufgaben. Quartalsweise.
- Typischer Rhythmus quartalsweise
- Die Checkliste 5 Abschnitte, 23 Punkte
- Variablen
{{scenario}}{{quarter}}
Mit dieser Checkliste testen Sie, ob Sie sich von einem Notfall tatsächlich erholen können, und nicht nur, ob ein IT-Notfallplan auf dem Papier existiert. Gemeint ist der Verlust eines ganzen Systems, einer Region, eines Rechenzentrums oder eines Cloud-Kontos, nicht die Wiederherstellung einer einzelnen Datei. Den Test für jedes kritische System mindestens ein- bis zweimal im Jahr durchführen und jedes Mal ein anderes Szenario wählen: Ausfall einer Region, Ransomware, gelöschtes Cloud-Konto, verlorene Datenbank.
Wer verantwortlich ist
Eine Testleitung ist für den Durchlauf verantwortlich. Sie wählt das Szenario, legt die Regeln fest (zum Beispiel „kein Zugriff auf die primäre Umgebung“), misst die Zeiten und dokumentiert die Ergebnisse. Die Schritte führen die Personen aus, die im Ernstfall wiederherstellen würden, idealerweise nicht jedes Mal dieselben.
Typische Fehler
- Test mit dem Autor des Plans. Wenn nur eine Person den Plan umsetzen kann, ist es kein Plan. Eine andere Person die Wiederherstellung allein anhand der Dokumentation durchführen lassen.
- Zugangsdaten im ausgefallenen System. Passwortmanager, SSO und Key Vaults sind oft selbst vom Ausfall betroffen. Prüfen, ob der Notfallzugang (Break-Glass) von außen funktioniert.
- „Läuft“ statt „funktioniert“ messen. Die Wiederherstellungszeit endet, wenn Nutzer einen echten Vorgang abschließen können, nicht wenn die VM bootet.
- Erkenntnisse, die nie behoben werden. Ohne Folge-Tickets beweist der nächste Test dieselben Lücken noch einmal.
Planen Sie den Durchlauf in Runbook quartalsweise ein. Die Historie zeigt dann, welches Szenario wann getestet und von wem abgenommen wurde, ein nützlicher Nachweis gegenüber Kunden und Prüfern.
Die Checkliste: IT-Notfalltest {{quarter}}: {{scenario}}
Test planen
-
Szenario
{{scenario}}und betroffene Systeme schriftlich festgehalten -
Wiederherstellungszeit (RTO) und maximaler Datenverlust (RPO) je System notiert
-
Testregeln vereinbart: was als verloren gilt, welche Zugriffe erlaubt sind
-
Testumgebung oder isoliertes Netz gewählt, damit der Test die Produktion nicht beeinträchtigt
Ein echtes Failover der Produktion ist ein gültiger Test, aber nur mit ausdrücklicher Freigabe und einem getesteten Rückweg.
-
Teilnehmende, Beobachter und Zeitnehmer benannt
-
Beteiligte über das Testfenster informiert
Wiederherstellen
-
Startzeit des Tests notiert
-
Notfall-Zugangsdaten (Break-Glass) vom Offline- oder Out-of-Band-Speicherort geholt
-
Infrastruktur ausschließlich nach dokumentiertem Verfahren neu aufgebaut oder umgeschwenkt
Jeden Schritt notieren, bei dem die Dokumentation falsch, lückenhaft oder mehrdeutig war.
-
Daten aus dem neuesten Backup oder Replikat wiederhergestellt
-
Anwendungskonfiguration, Secrets und DNS auf die wiederhergestellte Umgebung umgestellt
-
Zeitpunkt notiert, an dem der erste echte Nutzervorgang gelingt
Messen
-
Tatsächliche Wiederherstellungszeit mit dem RTO verglichen
-
Zeitstempel der neuesten wiederhergestellten Daten mit dem RPO verglichen
-
Datenintegrität geprüft: Anzahl Datensätze, neueste Einträge, Anhänge und Dateien
-
Abhängigkeiten geprüft: E-Mail, Zahlungen, Schnittstellen zu Drittanbietern, geplante Jobs
Rückschwenk und Aufräumen
-
Rückschwenk auf die primäre Umgebung abgeschlossen, falls die Produktion genutzt wurde optional
-
Testumgebung abgebaut und Testdaten gelöscht
-
Temporäre Zugangsdaten rotiert und Zugriffe entzogen
Nachbereitung
-
Ergebnisse dokumentiert: Zeiten, Lücken, Fehler in der Dokumentation
-
Folge-Tickets mit verantwortlicher Person und Frist angelegt
-
IT-Notfallplan und Runbooks mit den Erkenntnissen aktualisiert
-
Ergebnisse an die Geschäftsleitung berichtet und nächstes Szenario festgelegt
Checkliste als Markdown
Häufige Fragen
Was ist der Unterschied zwischen Backup-Test und Disaster-Recovery-Test?
Ein Backup-Test prüft, ob sich Daten aus einer Sicherung zurückholen lassen. Ein Disaster-Recovery-Test prüft, ob ein ganzer Dienst wieder in einen funktionierenden Zustand kommt: Infrastruktur, Daten, Konfiguration, Zugänge und Abhängigkeiten, innerhalb der Zielzeiten. Beides ist nötig, der Backup-Test läuft meist häufiger.
Wie oft sollte man einen IT-Notfalltest durchführen?
Als übliche Basis gilt mindestens einmal pro Jahr für jedes kritische System, viele Teams testen quartalsweise mit wechselnden Szenarien. Nach größeren Architekturänderungen, etwa einem neuen Cloud-Anbieter oder einer neuen Datenbank, erneut testen. Verträge oder Standards wie ISO 27001 können eigene Erwartungen festlegen.
Was bedeuten RTO und RPO?
Das Recovery Time Objective (RTO) ist die längste akzeptable Zeit, bis ein Dienst nach einem Notfall wieder funktioniert. Das Recovery Point Objective (RPO) ist der größte akzeptable Datenverlust, gemessen in Zeit. Nur ein Notfalltest zeigt zuverlässig, ob die tatsächlichen Werte diese Ziele erreichen.
Aktualisiert