Notfall-Wiederherstellungsplan: was er wirklich enthält

Fragen Sie in Ihrem Umfeld nach: „Wenn Ihr Hauptserver heute Abend abbrennen würde, wie lange bräuchte das Unternehmen, um wieder zu arbeiten?“ Sie ernten Schweigen oder grobe Schätzungen zwischen „ein paar Stunden“ und „keine Ahnung“. Genau diese Lücke schließt ein Notfall-Wiederherstellungsplan (Disaster Recovery Plan): Aus „wir haben Backups“ wird „wir sind in N Stunden wieder am Netz, verlieren im schlimmsten Fall M Minuten an Daten, und wir haben das schon einmal durchgespielt“.

RTO und RPO: die einzigen zwei Kürzel, die zählen #

Ein Notfall-Wiederherstellungsplan beruht auf zwei Zahlen, und das sind geschäftliche Entscheidungen, keine technischen. Der RTO (Recovery Time Objective): Wie lange hält der Betrieb ohne den Dienst durch? Der RPO (Recovery Point Objective): Wie viele Daten dürfen verloren gehen: die letzten Minuten, die letzte Stunde, der letzte Tag? Ein Buchhaltungsbüro kommt einen halben Tag ohne seine Software aus, darf aber keine Buchung verlieren; bei einem Onlineshop ist es umgekehrt. Solange die Geschäftsleitung diese beiden Zahlen nicht festgelegt hat, ist alles, was technisch darunter liegt, Justieren im Blindflug.

Ohne festgelegten RTO haben Sie trotzdem einen: den, den Sie am Tag des Ausfalls entdecken. Er ist in der Regel länger, als das Unternehmen verkraften kann.

Der tatsächliche Inhalt eines Notfall-Wiederherstellungsplans für KMU #

Vergessen Sie den 80-seitigen Ordner, der in einem Schrank verstaubt. Ein brauchbarer Notfall-Wiederherstellungsplan ist kurz, aktuell und vor allem von einer übermüdeten Person um 3 Uhr morgens ausführbar:

• Die Bestandsaufnahme nach Kritikalität: welche Dienste, welche Maschinen, welche Abhängigkeiten. Ohne sie wird in falscher Reihenfolge wiederhergestellt: die Anwendung vor ihrer Datenbank, die Datenbank vor dem DNS.
• RTO/RPO pro Dienst: Nicht alles ist gleich viel wert. E-Mail, Rechnungsstellung und Intranet haben weder dieselbe Dringlichkeit noch denselben Bedarf an Aktualität.
• Die schriftlichen Wiederherstellungsverfahren: nicht „den Server wiederherstellen“, sondern die Befehle, die Zugänge, die Kontrollpunkte. Existiert das Verfahren nur im Kopf einer einzigen Person, hat Ihr Plan einen menschlichen SPOF (Single Point of Failure).
• Die Startreihenfolge: Netzwerk, DNS, Datenbanken, Anwendungen, dann die Clients. Die Abhängigkeiten erzwingen eine Abfolge, also schreiben Sie sie besser in Ruhe auf.
• Rollen und Kontakte: wer über das Auslösen entscheidet, wer wiederherstellt, wer die Kunden informiert. Mit Telefonnummern, nicht „siehe Verzeichnis“, das womöglich auf dem ausgefallenen Server liegt.
• Die Auslösekriterien: Ab wann wechselt man von der Störungsbehebung zur Wiederherstellung? Die schlimmsten Verluste entstehen in den Stunden, in denen man versucht, einen Toten zu reparieren.

Die technischen Mittel, Stufe für Stufe #

Der Plan ist das Dokument; es braucht aber auch Mittel, die ihn tragfähig machen. Sie bauen in Stufen aufeinander auf, von der günstigsten bis zur anspruchsvollsten, und jede Stufe senkt RTO oder RPO:

1. Getestete, unveränderliche Backups außer Haus: das absolute Fundament, ohne das alles andere Dekoration ist. Diese Architektur haben wir in unserem Artikel zu 3-2-1 beschrieben. Typischer RPO: ein Tag oder eine Stunde; RTO: die Dauer der Wiederherstellung.
2. Replikation: Die Daten werden fortlaufend oder alle X Minuten auf einen zweiten Host kopiert. Der RPO sinkt auf wenige Minuten; der RTO entspricht der Dauer eines Failovers.
3. Hochverfügbarkeit: mehrere Knoten, automatisches Failover beim Ausfall eines Hosts. Der RTO sinkt auf wenige Minuten: bei Hardwareausfällen, nicht bei Ransomware oder menschlichen Fehlern, die sich genauso schnell replizieren wie die Daten.
4. Unabhängige Überwachung: Wer warnt Sie, wenn der Ausfall um 2 Uhr nachts passiert? Und wenn die Überwachung selbst ausfällt? Eine externe „Dead-Man“-Kontrolle (ein Sensor, der beim Schweigen des Überwachungssystems Alarm schlägt) schließt den Kreis.

Genau diesen Aufbau betreiben wir für unsere Kunden: Cluster mit mehreren Knoten und automatischem Failover, Replikation zwischen Hosts, tägliche unveränderliche Backups mit Kopie außer Haus und eine Überwachung, die von einem unabhängigen Watchdog ergänzt wird. Keiner dieser Bausteine ist exotisch; selten ist, dass sie alle vorhanden und geprüft sind.

Ein nie geübter Notfall-Wiederherstellungsplan ist Fiktion #

Der Tag des Ausfalls ist nicht der richtige Tag, um festzustellen, dass ein Passwort geändert wurde, dass ein Verfahren zwei Jahre veraltet ist oder dass eine Wiederherstellung sechs Stunden dauert statt zwei. Mindestens eine Übung pro Jahr: einen kritischen Dienst tatsächlich auf einem leeren Host wiederherstellen, die Zeit stoppen, das Verfahren korrigieren. Unsere erste vollständige Übung hat uns Details gezeigt, die keine Prüfung der Dokumentation aufgedeckt hätte: Genau dafür ist sie da. Die gestoppte Zeit der Übung ist Ihr echter RTO; vergleichen Sie ihn mit dem, den die Geschäftsleitung beschlossen hat, und Sie wissen, wo Sie investieren müssen.

Unsere Managed Services umfassen dieses Fundament (getestete Backups, Überwachung Tag und Nacht, Rufbereitschaft), und wir erstellen den Notfall-Wiederherstellungsplan gemeinsam mit Ihnen: Bestandsaufnahme, RTO/RPO mit der Geschäftsleitung festgelegt, schriftliche Verfahren, jährliche Übung. Wenn Sie die Frage aus dem ersten Absatz nicht beantworten können, ist jetzt der richtige Moment, darüber zu sprechen.