Disaster Recovery: Wiederanlaufplanung für den Ernstfall

Disaster Recovery bezeichnet die vorbereiteten technischen und organisatorischen Abläufe, mit denen ein Unternehmen nach einem schwerwiegenden IT-Ausfall wieder arbeitsfähig wird. Gemeint sind Ereignisse, die über eine einzelne defekte Festplatte hinausgehen: Brand, Wasserschaden, längerer Stromausfall, Ausfall eines Rechenzentrums oder ein Verschlüsselungsangriff über die gesamte Umgebung. Der Unterschied zum Backup liegt in der Reichweite: Backup liefert die Daten, Disaster Recovery beschreibt, wie daraus wieder ein funktionierender Betrieb wird.

Grundlage: Prioritäten und Zielwerte

Am Anfang steht eine Betrachtung der Geschäftsprozesse, nicht der Technik. Für jeden Prozess wird bestimmt, ab wann sein Ausfall spürbar wird und welche IT-Systeme ihn tragen. Daraus ergeben sich zwei Kennzahlen: Das Recovery Time Objective legt fest, wie lange ein System maximal ausfallen darf, das Recovery Point Objective, wie viel Datenverlust hinnehmbar ist.

Diese Werte müssen differenziert vergeben werden. Ein Auftragsabwicklungssystem, dessen Stillstand die Produktion anhält, verträgt möglicherweise vier Stunden. Ein Archivsystem verträgt drei Tage. Werden alle Systeme pauschal als hochkritisch eingestuft, entsteht ein Plan, der weder finanzierbar noch im Ernstfall abarbeitbar ist.

Warum ein KMU davon betroffen ist

Mittelständische Betriebe verfügen selten über zwei gleichwertige Rechenzentren. Häufig steht die gesamte Serverlandschaft in einem Raum am Hauptstandort, dessen Klimatisierung, Stromversorgung und Zugangsschutz nicht auf Katastrophenfälle ausgelegt sind. Gleichzeitig ist die Abhängigkeit von der IT vollständig: Ohne Warenwirtschaft, Telefonie und Dateiablage steht der Betrieb.

Hinzu kommt, dass Wiederanlauf nicht nur Technik erfordert. Wer darf im Ernstfall entscheiden, dass auf ein Ausweichsystem umgeschaltet wird? Wie erreichen Sie Ihre Beschäftigten, wenn Telefonanlage und Mailsystem ausgefallen sind? Wo liegt die Dokumentation, wenn der Dateiserver Teil des Schadens ist?

Bestandteile eines belastbaren Plans

Ein tragfähiger Wiederanlaufplan ist knapp, aktuell und auch unter Druck lesbar. Bewährt haben sich folgende Bestandteile:

• Priorisierte Liste der Systeme mit RTO, RPO und technischen Abhängigkeiten
• Festgelegte Wiederanlaufreihenfolge, beginnend bei Verzeichnisdienst, Netz und Namensauflösung
• Alarmierungskette mit Namen, Vertretung und Erreichbarkeit außerhalb der betrieblichen Systeme
• Zugangsdaten und Lizenzschlüssel in einem vom Produktivnetz unabhängigen, gesicherten Speicher
• Ausweichlösungen für den Übergangsbetrieb, etwa Papierprozesse oder Mobilfunkbasierte Kommunikation
• Kontaktdaten von Dienstleistern, Versicherung und gegebenenfalls Aufsichtsbehörde

Technisch reicht das Spektrum von einfacher Wiederherstellung aus dem Backup über einen zweiten Standort mit vorbereiteter Hardware bis zu laufender Replikation in eine Cloud-Umgebung. Die Wahl folgt den zuvor festgelegten Zielwerten und dem verfügbaren Budget, nicht umgekehrt.

Typische Fehler

Der wichtigste Fehler ist das Ausbleiben von Übungen. Ein Plan, der nie durchgespielt wurde, enthält verlässlich falsche Annahmen: veraltete Telefonnummern, nicht mehr vorhandene Hardware, Abhängigkeiten, die niemand auf dem Schirm hatte.

• Plan ausschließlich digital im betroffenen Netz abgelegt und im Ernstfall nicht erreichbar
• Wiederanlaufzeiten geschätzt statt gemessen, oft um den Faktor zwei bis drei zu optimistisch
• Externe Abhängigkeiten wie Internetanbindung, Lizenzserver oder Cloud-Dienste nicht berücksichtigt
• Keine Regelung, wer den Wiederanlauf auslöst, wenn die Geschäftsführung nicht erreichbar ist
• Bei Cyberangriffen fehlt die Abstimmung mit Spurensicherung, sodass Beweise vorschnell überschrieben werden

Realistisch ist ein Plan, der die wichtigsten Prozesse innerhalb definierter Fristen wieder verfügbar macht und für den Rest längere Fristen offen ausweist. Diese Ehrlichkeit ist wertvoller als ein umfassendes Dokument, das im Ernstfall niemand anwenden kann.

• Disaster Recovery beginnt bei den Geschäftsprozessen, nicht bei der Technik
• RTO und RPO je System differenziert festlegen, pauschale Einstufungen sind nicht umsetzbar
• Wiederanlaufreihenfolge und Abhängigkeiten dokumentieren, nicht nur die Systemliste
• Plan, Zugangsdaten und Kontakte außerhalb der betroffenen Umgebung verfügbar halten
• Ohne regelmäßige Übung bleiben die angenommenen Wiederanlaufzeiten unbelegt