Der Name legt es bereits nahe: Bei der sogenannten Disaster Recovery wird es ernst, denn verhandelt wird ein weiteres Mal eine Krisensituation. Und etwas genauer: Wenn ein kritischer IT-Vorfall eintritt, beschäftigt sich Disaster Recovery mit dem Wiederanlauf, aber auch mit der Wiederherstellung von durch eine Störung ausgefallenen oder beschädigten IT-Infrastrukturen, IT-Systemen und -Anwendungen. Um einen strukturierten Wiederanlauf oder eine Wiederherstellung ausgefallener IT-Infrastrukturen, IT-Systeme und -Anwendungen durchzuführen, ist es erforderlich, die entsprechenden Maßnahmen bereits im Voraus zu planen und zu organisieren. Die Planung und Organisation dieser Maßnahmen wird heutzutage als IT Service Continuity Management / Disaster Recovery Management bezeichnet. Dazu eine kurze begriffliche Klärung: Die Bezeichnung Disaster Recovery stammt bereits aus den 70er-Jahren und ist heute nicht mehr so ganz zeitgemäß. Disaster Recovery fokussierte sich dabei vorwiegend auf die operative Bewältigung eines IT-Notfalls. Vielmehr wird heute der Begriff „IT Service Continuity Management“ (kurz ITSCM) verwendet und diese Bezeichnung wird deshalb auch im Folgenden in diesem Artikel eingesetzt.

Disaster Recovery – Definition des Krisenfalls

Die Notfallszenarien für das IT Service Continuity Management basieren auf dem Worst-Case-Szenario-Ansatz (Ausfall Rechenzentrum, Ausfall WAN oder der RZ-Kopplung, Nichtzugängigkeit eines RZ). Mit einbezogen wird jede kritische Situation und die durch sie bedingte schädliche Einwirkung, die dazu führen kann, dass IT-Infrastrukturen, IT-Systeme und -Anwendungen ausfallen und Daten verloren gehen können. Denkbare Ursachen für den Ausfall von Rechenzentren sind seismische oder klimatische Naturkatastrophen, wie Erdbeben, Hochwasser, Unwetter und Orkane, aber auch Feuer oder der Ausfall der Stromversorgung. Ebenso denkbar sind kriminelle Handlungen. All diese Faktoren können dann wiederum zum Ausfall von IT-Infrastrukturen, IT-Systemen und -Anwendungen und/oder zu einem Verlust von Daten führen. Und es ist dann Aufgabe des ITSCM, jene IT-Services und Daten wiederherzustellen beziehungsweise diese wiederanlaufen zu lassen.

Wo genau befinden sich diese Daten und Funktionen?

Fast alle Geschäftsprozesse eines Unternehmens benötigen heutzutage eine funktionsfähige IT. Somit kommt dem Disaster Recovery oder ITSCM als weiterführendes Managementsystem eine sehr wichtige Rolle bei der Arbeitsfähigkeit eines Unternehmens zu. ITSCM-relevante Systeme sind Teil des täglichen Schaffens: Typische IT-Infrastrukturen, IT-Systeme und -Anwendungen sind zum Beispiel Datennetzwerke (LAN), Speichernetzwerke (SAN), Mainframes, Serversysteme, Datenbanken, Middleware, Anwendungssoftware und auch Telefonanlagen.

Ziel von Disaster Recovery/ITSCM

Am Ende dient Disaster Recovery beziehungsweise ITSCM dem übergeordneten Ziel, den potenziellen Schaden für das von einem kritischen IT-Vorfall oder von einem Ausfall betroffene Unternehmen so gering wie möglich zu halten.

Disaster Recovery im Unterschied zum Business Continuity Management

Ist man auf der Suche nach einer deutschen Disaster-Recovery-Definition, dann lässt sich der Begriff am ehesten mit IT-Notfallmanagement übersetzen. Obwohl häufig als Synonym verwendet, ist Disaster Recovery übrigens nicht mit dem Business Continuity Management (BCM) zu verwechseln. Das BCM bezieht sich auf einen sehr viel breiteren Bereich und sichert vor allem das Fortbestehen des Geschäftsbetriebs. So beschäftigt sich das BCM mit der generellen Weiterführung und Aufrechterhaltung aller zeitkritischen Geschäftsprozesse in einem Notfallszenario. Dahingegen beschränkt sich Disaster Recovery auf den Wiederanlauf und die Wiederherstellung von IT-Infrastrukturen, IT-Systemen und -Anwendungen und deren Daten in potenziellen IT-Notfall-, IT-Ausfall- und IT-Störungssituationen. Das Disaster Recovery beziehungsweise das ITSCM beleuchtet damit lediglich einen Teilbereich der durch das BCM abgedeckten Prozesse und Systeme.

Wie sieht ein sinnvolles Disaster-Recovery-Konzept aus?

Wie das BCM hat auch Disaster Recovery/ITSCM die Aufgabe, betreffende Systeme für einen IT-Notfall abzusichern, sodass folglich natürlich bereits im Vorhinein geplant werden muss. Die Erstellung eines Disaster-Recovery-Konzepts oder auch der sogenannten Disaster-Recovery-Pläne ist an dieser Stelle unerlässlich.

Der Disaster-Recovery-Plan (DRP)

Der Disaster-Recovery-Plan (kurz DRP) umfasst alle Maßnahmen und Regelungen, die im Fall der Fälle einen erfolgreichen Wiederanlauf ermöglichen. Das bedeutet im Umkehrschluss: Zuvor müssen alle unternehmenskritischen IT-Infrastrukturen, IT-Systeme und -Anwendungen erkannt werden.

Maßnahmen des Disaster-Recovery-Plans

Der Disaster-Recovery-Plan enthält alle nötigen Maßnahmen und Regelungen, die in einem Ausfallszenario erforderlich sind, um IT-Infrastrukturen, IT-Systeme und -Anwendungen schnellstmöglich wieder in Gang zu setzen. Dementsprechend sind Bestandteile dieser Maßnahmen zum Beispiel eine Bereitstellung von ersatzweiser Hardware (bei Hardwarestörung oder -ausfall), aber auch Schritte zur Datenrücksicherung und Ähnliches. Außerdem werden im Disaster-Recovery-Plan im Notfall verantwortliche Personen sowie das schrittweise Vorgehen bei der Umsetzung der Maßnahmen benannt, um einen reibungslosen Ablauf zu gewährleisten.

Probe aufs Exempel: Disaster-Recovery-Test

Die tatsächliche Wirksamkeit des DRPs will erprobt sein und der Plan sollte deshalb regelmäßig unter authentischer Einbeziehung aller verantwortlichen Mitarbeiter getestet und durchgespielt werden. So zeigt sich, was in puncto Wiederherstellung und Wiederanlauf von IT-Infrastrukturen, IT-Systeme und -Anwendungen bereits funktioniert und was noch verbessert werden kann. Hierfür muss eine strategische Planung mit Jahresplanung erfolgen.

Wichtige Kennzahlen für erfolgreiche Disaster Recovery

Es gibt Kennzahlen, die Anhaltspunkte für die Disaster Recovery/das ITSCM bieten und sich auf die Gestaltung späterer Notfallmaßnahmen auswirken. Die dafür wichtigsten Werte sind die Recovery Time Objective und die Recovery Point Objective. Sie werden jeweils für zeitkritischen Geschäftsprozesse einzeln definiert und müssen durch das ITSCM eingehalten werden.

Recovery Time Objective (RTO)

Zeitfaktor: Wie lang darf ein zeitkritischer Geschäftsprozess maximal ausfallen? Diese Kennzahl ist sehr variabel und fällt sehr unterschiedlich aus, je nach Bedeutung des Systems.

Recovery Point Objective (RPO)

Verlustfaktor: Verlust von wie viel Daten ist akzeptabel? Hierbei geht es um die Daten, die zwischen zwei Datensicherungen verloren gehen. Je niedriger der Wert des RPOs ist, desto weniger Datenverlust ist also zu verzeichnen.