Disaster-Recovery-Test für Unternehmen
Ein Disaster-Recovery-Test prüft, ob die vorhandenen Sicherungen ausreichen, um zentrale Unternehmenssysteme außerhalb der eigenen Infrastruktur wieder aufzubauen. Im ITN Recovery Lab passiert das auf getrennter Infrastruktur — Ihre Produktivumgebung bleibt unberührt.
Was vor dem Test festgelegt wird
Die Qualität eines Disaster-Recovery-Tests entscheidet sich in der Vorbereitung. Fünf Punkte, ohne die ein Test am Ende nur ein Gefühl hinterlässt.
Umfang
Welche Systeme gehören zum Test? Sinnvoll ist der Kern, der den Betrieb trägt — nicht alles, was existiert.
Reihenfolge
Welches System muss zuerst laufen? Verzeichnisdienst und Namensauflösung vor Datenbank, Datenbank vor Applikationsserver. Diese Reihenfolge ist im Ernstfall genau die Information, die fehlt.
Bekannte Abhängigkeiten
Was wissen Sie bereits über Dienste, die aufeinander warten, über fest verdrahtete Adressen und über Lizenzserver? Der Test findet den Rest.
Erfolgskriterien
Welche Prozesse müssen am Ende nachweislich funktionieren? Diese Kriterien legen Sie fest — Sie prüfen sie später auch selbst.
Rollen
ITN stellt die isolierte Umgebung bereit, führt die Wiederherstellung durch und startet die Systeme. Sie prüfen die fachliche Funktionsfähigkeit und nehmen ab. Auf Wunsch dokumentieren wir das Ergebnis.
- ITN: Restore und Boot
- Kunde: Funktionsprüfung
- Dokumentation auf Wunsch
Zielwerte praktisch prüfen statt nur definieren
In vielen Unternehmen stehen RTO und RPO in einem Dokument: Die Wiederanlaufzeit soll vier Stunden betragen, der maximale Datenverlust eine Stunde. Beide Werte sind Vorgaben — keine Messwerte. Ob sie erreichbar sind, weiß niemand, solange es keinen Versuch gegeben hat.
Ein Test verschiebt die Diskussion von der Annahme zur Beobachtung. Er zeigt, wie lange die Wiederherstellung der ausgewählten Systeme tatsächlich gedauert hat, an welcher Stelle es hakte und welcher Datenstand am Ende zur Verfügung stand. Daraus wird entweder die Bestätigung Ihrer Zielwerte — oder die begründete Korrektur.
Wichtig zur Einordnung: Die gemessene Dauer eines Tests ist keine Zusage für den Ernstfall. Sie ist ein belastbarer Anhaltspunkt, wo Sie stehen — mehr als eine Zahl im Konzeptpapier, weniger als eine Garantie.
Der Zeitbedarf ergibt sich aus dem Test, nicht aus einer Herstellerangabe.
Meist ist es nicht die Datenmenge, sondern eine Abhängigkeit, die den Wiederanlauf aufhält.
Sie sehen am wiederhergestellten System, welcher Stand tatsächlich vorliegt.
Ein gescheiterter Teiltest ist kein schlechtes Ergebnis, sondern der eigentliche Nutzen.
Was ein Disaster-Recovery-Test nicht ist
Damit die Erwartung stimmt, drei klare Grenzen.
Kein Schutz
Ein Test verhindert keinen Ausfall und keinen Angriff. Er sagt nur, ob Sie danach wieder anlaufen können.
Keine Forensik
Wir untersuchen keine Angriffe und werten keine Spuren aus. Ein Test ist eine geplante Übung, kein Notfalleinsatz.
Ein Nachweis
Das Ergebnis ist eine überprüfte Aussage über Ihre Wiederanlauffähigkeit zum Testzeitpunkt — auf Wunsch dokumentiert.
Häufige Fragen zum Disaster-Recovery-Test
Was gehört in einen Disaster-Recovery-Testplan?
Der Umfang der zu testenden Systeme, die Reihenfolge ihrer Wiederherstellung, die bekannten Abhängigkeiten, die Erfolgskriterien und die Rollen: wer stellt wieder her, wer prüft fachlich, wer entscheidet über die Abnahme. Ohne festgelegte Erfolgskriterien lässt sich hinterher nicht sagen, ob der Test erfolgreich war.
Wie hängen RTO und RPO mit einem Test zusammen?
RTO und RPO sind Zielwerte, die ein Unternehmen für sich festlegt. Ein Test macht sichtbar, ob diese Werte unter realen Bedingungen erreichbar sind. Erst wenn eine Wiederherstellung einmal durchgeführt wurde, lässt sich der Zeitbedarf einschätzen statt schätzen.
Sagt ITN eine bestimmte Wiederherstellungszeit zu?
Nein. Wir sagen vorab keine Wiederherstellungsdauer zu, weil sie von Ihrer Umgebung abhängt — Datenmenge, Anzahl der Systeme, Abhängigkeiten und Format der Sicherungen. Was der Test tatsächlich gebraucht hat, halten wir auf Wunsch in der Dokumentation fest. Das ist eine Messung, keine Zusage.
Wie unterscheidet sich das von einem Notfallhandbuch?
Ein Notfallhandbuch beschreibt, was im Ernstfall geschehen soll. Ein Test zeigt, ob es funktioniert. Beides gehört zusammen: Die Erkenntnisse aus einem Test sind meist die wertvollsten Korrekturen am Handbuch, weil sie aus der Praxis kommen und nicht aus der Annahme.
Muss der Test die komplette IT umfassen?
Nein, und meistens ist das auch nicht sinnvoll. Aussagekräftig ist der Kern, der den Betrieb trägt. Ein Test über wenige, richtig ausgewählte Systeme sagt mehr als ein Rundumschlag ohne klare Erfolgskriterien.
Weiter im Thema: Cyber Recovery, wenn die eigene Infrastruktur nicht mehr vertrauenswürdig ist, oder Backup-Wiederherstellung testen als Einstieg. Übersicht im Recovery Lab.