Desaster-Recovery umfasst alle Strategien und Maßnahmen, die ergriffen werden, um IT-Systeme, Daten und die Infrastruktur nach einem schwerwiegenden Vorfall oder einer Katastrophe wiederherstellen zu können. Vorfälle können von Naturkatastrophen wie Erdbeben oder Überschwemmungen bis hin zu technischen Störungen, Cyberangriffen oder menschlichem Versagen reichen.
Grundvoraussetzung sollte stets ein Back-up-Konzept und durchgeführte Daten- und Systemsicherungen sein (siehe dazu unseren Blogbeitrag Back-up early – Back-up often), denn nur was wir sicher bewahren können wir im Notfall wiederherstellen.
Bevor wir uns mit dem Desaster-Recovery, Anforderungen an dieses, Konzeption und Durchführung befassen, wollen wir an dieser Stelle ein paar typische Angriffsszenarien betrachten, die allesamt tatsächlich so geschehen sind und leider auch wieder vorkommen könnten.
Angriffsszenarien
Ein Klick und die Daten sind futsch
Tatsächlich ist mir dieses Szenario in meiner Laufbahn mehrfach untergekommen. Das Vorgehen des Angreifers ist dabei simpel: Einigen oder allen Mitarbeiter wird eine Mail mit einem Trojaner zugeschickt in der Hoffnung das einer daraufklickt. In der einfachen Variante läuft die Verschlüsselung direkt los, aber dann reichen einfache Back-ups zur Wiederherstellung aus – falls man Back-ups überhaupt durchführt. Bei zwei meiner Kunden war die Verschlüsselung perfider. Denn beim Öffnen des korrupten Anhangs schien erst einmal überhaupt nichts zu passieren. Der Trojaner verteilte sich heimlich im gesamten Netz und begann, die Back-Ups zu kompromittieren. Das heißt, diese wurden fehlerhaft abgespeichert bzw. direkt verschlüsselt. Da beide Kunden noch kein echtes Desaster-Recovery besaßen, bemerkten sie diesen Fehler nicht. Erst als die Verschlüsselung aller Daten vom Trojaner durchgeführt wurde, erkannte man, dass die Back-ups unbrauchbar waren. In beiden Fällen konnten wir hinzugerufen nun nicht mehr wirklich helfen. Der Datenverlust bei dem einen Unternehmen war absolut, beim anderen war ein Großteil der Systeme und Daten nicht widerherstellbar. Kosten für beide waren mehrere Monatsumsätze, um die IT wieder ans Laufen zu bringen. Beim zweiten Unternehmen immerhin mehrere hundert Millionen Euro.
Der Südwestfalen-IT, einem Rechenzentrum für Städte und Gemeinden, erging es ähnlich. Hier dauerte es mehr als einen Monat bevor man die ersten Server wieder ans laufen brachte, selbst nach sechs Monaten war die Wiederherstellung noch nicht abgeschlossen und ein Teil der Daten konnte auch dann nicht mehr gerettet werden. Einige Städte und Gemeinden konnten über Monate keine Personalausweise oder Führerscheine mehr herausgeben, weil man keine Möglichkeit hatte, die Anwendungen zu starten.
Mit Social-Hacking bis zum Herrn der IT

Bei einem anderen späteren Kunden war das Vorgehen anders. Per Social-Hacking wurde der Account eines ganz normalen Mitarbeiters geknackt. In diesem Fall hatte dieser keine speziellen Rechte, konnte sich aber gewisse administrative Rechte von der IT geben lassen. Der Hacker beantragte diese Rechte und konnte anhand dieser Rechte ein weites Konto in seine Gewalt bringen. Schrittweise baute er die Rechte der gehackten Konten aus, bis er schließlich in der Lage war, sich selbst ein administratives Konto zu erstellen, für das er schließlich sogar alle Root-Rechte setzen konnte. Im nächsten Schritt wurden Schlüssel getauscht und die bisherigen Administratoren ausgeschlossen. Im letzten Schritt erfolgten Datenabfluss und -löschung.
Hier stoßen mehrere Fehler aufeinander: die Vergabe an IT-Rechte an normale Anwender, die Möglichkeit seine Rechte zu erweitern auf der einen Seite und das Fehlen vollständiger Back-ups und Recovery-Tests auf der anderen Seite. Auch bei diesem Kunden konnten wir nur einen Teil der Daten wiederherstellen und ein neues Sicherheitskonzept für die Zukunft einführen. Neben dem Vertrauensverlust bei den Kunden kamen verlorene Daten hinzu und kosten über einige Millionen Euro im zweistelligen Bereich.
Desaster-Recovery
Das Hauptziel das wir mit dem Thema Disaster-Recovery erreichen wollen ist es, die Verfügbarkeit von kritischen IT-Diensten zu gewährleisten und die Auswirkungen eines Ausfalls auf das Unternehmen zu minimieren. Das bedeutet, dass sowohl Daten als auch die IT-Systeme selbst in möglichst kurzer Zeit wiederhergestellt werden sollen und Datenverluste so weit wie möglich minimiert werden.
Vorraussetzungen für ein erfolgreiches Disaster-Recovery sind dabei
- ein Disaster-Recovery-Plan (DRP): Der DRP ist ein dokumentierter Ansatz, der beschreibt, wie ein Unternehmen auf verschiedene Arten von Katastrophen reagieren wird. Wir sprechen in diesem Fall auch gerne von einem Recovery-Konzept. Der Plan enthält alle Details zu den erforderlichen Ressourcen, den Verantwortlichkeiten der Mitarbeiter, den Wiederherstellungsprozessen und den Kommunikationsstrategien, sodass man anhand dieses Planes die gesamte Datenwiederherstellung durchführen kann. Der Plan betrachtet dabei das Zusammenspiel von Netzwerken, Infrastruktur, einzelnen Systemen, der Software und den Daten.
- ein Back-up-Konzept: Regelmäßige Datensicherungen sind ein wesentlicher Bestandteil von Disaster-Recovery. Nur Systeme und Daten die ohne Fehler gesichert wurden, lassen sich ohne Probleme wiederherstellen. Verschiedene Back-up-Strategien, wie vollständige Backups, inkrementelle Backups und differenzielle Backups, können dazu kombiniert werden, um Datenverlust zu minimieren.
- ein Daten-Wiederherstellungs-Test: Nur mit einem Testplan lässt sich verifizieren, um die gesicherten Systeme, Anwendungen und Daten überhaupt wiederherstellbar sind und ob sie in ihrem Zusammenspiel funktionieren.
Für ein erfolgreiches Desaster-Recovery spielen verschiedene Aspekte eine wichtige Rolle:
- Die Wiederherstellungszeit (RTO) und Wiederherstellungs-Punkt-Ziel (RPO) sind zu definieren und ebenso zu überprüfen. Die RTO ist die maximale akzeptable Zeit, die benötigt wird, um Systeme nach einem Ausfall wiederherzustellen (beispielsweise 3 Tage). Der RPO hingegen ist der maximale Zeitraum, in dem Daten verloren gehen dürfen, was die Häufigkeit von Back-ups beeinflusst (zum Beispiel Daten aus den letzten sechs Monaten, und die zum Zeitpunkt des Vorfalls älter als 30 Minuten waren). Der maximale Zeitraum kann dabei durch eine längere Aufbewahrung von Back-ups ermöglicht werden, das Mindestsalter kann durch eine höhere Sicherungsfrequenz gesenkt werden.
- Regelmäßige Tests anhand des DRP sind entscheidend, um sicherzustellen, dass die Wiederherstellungsprozesse funktionieren und die Mitarbeiter mit den Verfahren vertraut sind. Diese Tests helfen auch, Schwächen im Plan zu identifizieren und zu beheben. Hierbei werden immer wieder ganze Systeme und Datenbereiche hergestellt. Durch wird zum einen sichergestellt, dass die Back-ups nicht korrupt sind und zweitens, dass der DRP aktuell ist.
- Regelmäßige Schulungen tragen dazu bei, dass die Mitarbeiter über die Desaster-Recovery-Strategien informiert sind und wissen, wie sie im Falle eines Vorfalls reagieren sollen. Schulungen und regelmäßige Updates können helfen, die Bereitschaft zu erhöhen und die Mitarbeiter bzgl. der Gefahren zu sensibilisieren.
Neben dem Disaster-Recovery für eigene Server sollte mit der zunehmenden Nutzung von Cloud-Diensten auch eine Cloud-Disaster-Recovery-Strategie implementiert werden, die Flexibilität und Skalierbarkeit bietet. Es ist dabei zu beachten, dass die meisten Cloud-Anbieter keine Garantie für die Daten innerhalb der Dienste bieten, wenn zum Beispiel eine Verschlüsselung im Bereich der Kunden stattfindet. Hierzu müssen die Daten also eigenständig wiederhergestellt werden können-
Insgesamt ist Disaster-Recovery ein kritischer Bestandteil des Risikomanagements von Unternehmen, um die Geschäftskontinuität zu gewährleisten und sich gegen unvorhergesehene Ereignisse abzusichern.
Entwicklung eines DRPs

Die Entwicklung eines DRPs ist, obwohl das Vorgehen an sich klar ist, keine simple Sache. Es gibt viele Faktoren, die voneinander abhängig sind und gemeinsam betrachtet werden müssen. Die Verstrickungen zwischen Systemen, verschiedenen Anwendungen und der Kompatibilität zwischen den Daten und den Anwendungen sind zum Teil immens und führen dazu, dass die Komplexität sehr groß werden kann. Viele Faktoren müssen daher im Einzelfall genauer betrachtet werden. Das Grundsätzliche Vorgehen lässt sich jedoch in mehreren klaren Schritten einteilen:
- Bedarfsanalyse und Risikobewertung
- Identifikation von kritischen Geschäftsprozessen: Ermitteln Sie, welche Prozesse für den Betrieb des Unternehmens unerlässlich sind und priorisieren Sie diese. Das ist wesentlich, damit sie bei einer Wiederherstellung zuerst die kritischen Prozesse neu aufsetzen können.
- Risikobewertung: Analysieren Sie potenzielle Bedrohungen und Schwachstellen, die sich auf diese Prozesse auswirken könnten.
- Wahrscheinlichkeits- und Auswirkungenseinschätzung: Bewerten Sie die Wahrscheinlichkeit von Risiken und deren mögliche Auswirkungen auf das Unternehmen.
- Festlegung von Zielen
- Definieren Sie die Wiederherstellungsziele für Ihre gesamte Infrastruktur und einzelne Elemente. Die Wiederherstellungsziele können sehr unterschiedlich sein. Bei Ausgangsrechnungen reicht Ihnen vielleicht, wenn diese Tagesaktuell gesichert werden, weil Sie sie notfalls noch einmal erzeugen können. Allerdings benötigen Sie diese ggf. für einen größeren Zeitraum. Bestellungen oder Buchungen aus einem Online-System sind ggf. Transaktionskritisch und keine einzige Transaktion darf verloren gehen. Möglicherweise benötigen Sie aber nur aktuelle Transaktionen aus einigen Wochen, da diese danach in anderen Systemen abgerechnet und dokumentiert sind. In solchen Fällen müssen die Ziele für einzelne Systeme und Daten festgelegt werden.
- Wiederherstellungszeit RTO: Die maximale Zeitspanne, in der ein Prozess nach einem Desaster wiederhergestellt werden muss.
- Wiederherstellungs-Punkt-Ziel RPO: Der maximale Datenverlust, den das Unternehmen akzeptieren kann, gemessen in der Zeit vor dem Desaster.
- Ressourcenanalyse
- Inventarisierung von Ressourcen: Erfassen Sie alle notwendigen Ressourcen, einschließlich Hardware, Software, Daten und Personal, die für die Wiederherstellung erforderlich sind.
- Dokumentation von Abhängigkeiten: Erstellen Sie ein Diagramm der Abhängigkeiten zwischen verschiedenen Systemen und Prozessen.
- Wichtig ist sich stets zu verinnerlichen, dass bestimmte Software eine entsprechende Hardware und Infrastruktur voraussetzt, dass Daten einer bestimmten Software-Version ggf. nicht kompatibel zu einer anderen Software-Version sind, dass bestimmte Software-Versionen miteinander nicht funktionieren, dass bevor ein System X installiert und aufgesetzt werden kann, ein anderes System A existieren muss, dass ggf. bestimmte Rechte zum Installieren, Wiederherstellen und Testen notwendig sind und Personal ggf. nicht auf alle Bereiche gleichermaßen Zugriff hat und auch nicht alle Kompetenzen bei jedem Mitarbeiter geschult wurden.
- Entwicklung des Plans
- Strategien zur Wiederherstellung: Entwickeln Sie spezifische Strategien zur Wiederherstellung der kritischen Systeme und Prozesse. Dazu gehört auch eine Gewichtung der Systeme nach Geschäftskritikalität bzw. Erfordernis für andere Systeme.
- Dokumentation: Erstellen Sie eine ausführliche Dokumentation des Plans, die klar beschreibt, wer was tun muss, wenn ein Desaster eintritt.
- Kommunikationsplan: Legen Sie fest, wie Informationen während eines Notfalls kommuniziert werden sollen, sowohl intern als auch extern.
- Implementierung
- Schulung der Mitarbeiter: Schulen Sie alle relevanten Mitarbeiter im Umgang mit dem Desaster-Recovery-Plan und den notwendigen Verfahren.
- Bereitstellung von Handbüchern: Stellen Sie Diagramme, Handbücher, OnePager und Kommunikationspläne für alle bereit, damit diese im Notfall auch ohne funktionierende IT verfügbar sind. Das bedeutet, dass Sie im Ernstfall ggf. sogar Druckexemplare benötigen.
- Technologische Implementierung: Stellen Sie sicher, dass alle notwendigen Technologien und Systeme zur Unterstützung des DRPs implementiert sind. Dazu gehören Back-up- und Wiederherstellungssoftware, Testsysteme, Back-up-Systeme usw.
- Verwahrung der Back-ups: Wichtig ist, dass Back-ups so aufbewahrt werden, dass sie zum einen im Notfall verfügbar ist, zweitens aufgrund einer Katastrophe aber auch nicht verloren gehen (wir verweisen an dieser Stelle auf das Back-up-Konzept).
- Testen und Überprüfen
- Regelmäßige Tests: Führen Sie regelmäßige Tests des DRPs durch, um sicherzustellen, dass der Plan in der Praxis funktioniert. Dies kann durch Simulationen oder vollständige Übungen geschehen.
- Auch die Back-ups an sich müssen dabei getestet werden, denn kompromittierte, fehlerhafte oder unvollständige Back-ups helfen Ihnen im Ernstfall nicht weiter.
- Feedback sammeln: Nach jedem Test Feedback von den Teilnehmern einholen und den Plan entsprechend anpassen.
- Wartung und Aktualisierung
- Regelmäßige Überprüfungen: Überprüfen Sie den Plan regelmäßig und aktualisieren Sie ihn bei Änderungen in der Unternehmensstruktur, Technologie oder dem Geschäftsbetrieb. Auch Aktualisierungen von Hard- und Software, Einführung neuer Systeme oder Datenstrukturen müssen dabei Beachtung finden.
- Dokumentation von Änderungen: Halten Sie alle Änderungen und deren Begründungen fest, um eine nachvollziehbare Historie des Plans zu gewährleisten. Hierbei ist auch zu beachten, dass Back-ups aus einer älteren Sicherung auf Basis eines älteren DRPs ggf. ein anderes Vorgehen benötigen, als aktuelle Back-ups aus dem aktuellen DRP.
- Notfallkontaktliste
- Erstellung einer Kontaktliste: Halten Sie eine aktuelle Liste von Kontakten, die im Notfall schnell erreichbar sein müssen, z. B. IT-Personal, externe Dienstleister und wichtige Führungskräfte.
- Ein strukturierter Desaster-Recovery-Plan hilft Unternehmen, sich auf unerwartete Ereignisse vorzubereiten und die Auswirkungen auf den Geschäftsbetrieb zu minimieren.
- Schulungen
- Führen Sie Regelmäßig Awareness-Schulungen aller Mitarbeiter durch, um das Risiko von Vorfällen zu minimieren.
- Schulen Sie ihre IT-Mitarbeiter und verantwortliche Personen entsprechen regelmäßig, damit die Notfallpläne im Ernstfall schnell, zielführend und Fehlerfrei abgearbeitet werden können. Gleiches gilt selbstverständlich auch für die Tests und deren Prüfung. Was nutzen Ihnen Tests, wenn diese nicht korrekt durchgeführt werden und somit die Funktionalität Ihres DRPs nicht gewährleistet ist.
Unser Vorgehen
Für uns sind Back-up-Konzept und Desaster-Recovery-Pläne eng miteinander verbunden und zusammen als erweitertes Back-up-Konzept Teil unserer IT-Governance & Compliance-Strategie, bei der wir Ihnen gerne helfen können, dass das Zusammenspiel von Ablage, Löschen, Nutzung, Back-ups und Cybersecurity passt. Wenn Sie mit uns ein über Desaster-Recovery sprechen möchten, eine auf Ihre Bedürfnisse angepasste Planung benötigen, dann bieten wir Ihnen dafür das erweiterte Back-up-Konzept zu dem Sie zusätzlich OnePager mit Handlungsanweisungen für die Administratoren, Vorschläge für Mitarbeiterschulungen, eine Roadmap für ein weiteres Vorgehen und die Möglichkeit zur individuellen und passgenauen Umsetzung durch unsere Partner oder andere Systemhäuser erhalten.

Haben Sie weitere Fragen zur Konzeption oder zur Implementierung? Die HOLAGIL freut sich darauf, Ihre Fragen beantworten zu dürfen und unterstützt Sie gerne dabei, mit den nächsten Schritten fortzufahren. Nehmen Sie jetzt Kontakt zu uns auf, um ab sofort zu finden statt zu suchen.