DRP – 3 Buchstaben für Ihr IT-Überleben

Ein gutes Backup-System gehört heute selbstredend zu jeglichem Einsatz von IT-Systemen. Egal ob Freiberufler, Kleinbetrieb oder Großunternehmen – ohne Datensicherung gleicht das Vertrauen in die EDV dem Risiko beim Russischen Roulette. Auch die heute angesagten Cloud-Systeme ändern daran nichts, denn ein Datenverlust kann vielfältige Ursachen haben. Der Einsatz von Bandlaufwerken oder Festplatten-Sicherungssystemen mit entsprechender Software ist aber nur die halbe Miete. Nur ein begleitender Plan macht aus Technik eine Handlungsmöglichkeit – die Rede ist vom Desaster Recovery Plan.

Nie für möglich gehalten?

Die Schäden durch den Ausfall eines IT-Systems können enorme Ausmaße annehmen. Nicht nur finanzielle, sondern auch Verluste im Imagebereich können Firmen bei Nichtverfügbarkeit von Anwendungen und Prozessen heftig in Mitleidenschaft ziehen. Im Extremfall kann ein Stillstand zentraler Applikationen sogar zur Insolvenz führen.
Diesen Gefahren gegenüber steht die Tatsache, dass EDV-Systeme immer Gefahr laufen, einmal auszufallen und auch die beste und teuerste Technik diesen Umstand nur beeinflussen, aber nie aufheben wird. Dazu kommt noch die menschliche Komponente. Sowohl Administratoren wie auch Anwender machen Fehler – und diese gilt es einzukalkulieren. Zuletzt führt nicht selten eine Fehlfunktion von Software oder ein Virus zur Datenvernichtung. All diese Szenarien müssen folglich Bestandteil jeder EDV-Planung sein.

Backup allein ist zu wenig

Vorsorge ist das Schlagwort zur Absicherung vor derartigen Katastrophen. Es gilt die entscheidende Produktivität des Unternehmens schnellstmöglich wiederherzustellen. Und da ist das Backup nur ein Bestandteil eines Gesamtkonzepts. Die Gesamtdauer bis zur wiederaufgenommenen Funktionsfähigkeit ist entscheidend – und dazu gehört viel mehr als nur eine digitale Sicherung auf einem Datenträger.
Ersetzen wir den Begriff Backup durch Notfall-Management, so kommen wir den Anforderungen um einiges näher. Zum ersten sprechen wir dabei über die notwendige Wiederherstellung von Daten oder ganzen Systemen (wesentlich aufwendiger als die Sicherung) und zum zweiten von einer Planung, die menschliche Ressourcen miteinbezieht. Nicht zuletzt muss hervorgehoben werden, dass es dabei – wie beim IT-System auch – um einen lebenden Prozess geht. Änderungen an Technik und Zuständigkeiten müssen in dieses Notfall-Management eingepflegt und stets aktualisiert werden.

Jetzt oder nie!

Ein Desaster-Recovery-Plan ist – wie der Name schon sagt – eine Dokumentation des Ablaufs, der im Notfall auszuführen ist. Wer erst beim Eintritt der Katastrophe die notwendigen Tätigkeiten und Personen plant, verschwendet im besten Fall wichtige Zeit. Im schlimmsten Fall scheitert die Wiederherstellung ganz. Sehen wir uns die entscheidenden Bestandteile eines DR-Plans genauer an:

Analyse der Geschäftsprozesse

Wer sich jetzt fragt, was denn Geschäftsprozesse mit dem Backup zu tun haben, der hat noch nie einen Verlust wichtigster Daten erlebt oder einen solchen in Gedanken durchgespielt. Erst die Identifikation und Dokumentation aller Geschäftsprozesse, die für das Unternehmen von entscheidender Bedeutung sind, ermöglicht eine realistische Einschätzung der notwendigen Backup- und Recovery-Prozesse. Des Weiteren ist eine Aufstellung aller involvierten IT-Systeme (Hard- und Software, Anwenderdaten, Applikationen) unerlässlich.

Risikoanalyse

Wissen Sie, welches System und welche Anwendungen Ihrer Infrastruktur im Fall eines Ausfalls eine „Katastrophe“ zur Folge haben? Und jetzt bitte keine vorschnelle Antwort aus der Hüfte schießen. Diese Haltung ist der Anfang jedes Desasters. Bereits ein „Übersehen“ eines wichtigen Switches kann die gesamte Verfügbarkeit wichtiger Anwendungen für einen Tag oder mehr lahmlegen.
Die erforderliche Risikoanalyse muss als Mindestanforderung eine grobe Schätzung der Ausfallskosten, eine Aufstellung eventueller Gefahren und Bedrohungen sowie eine Skizzierung der Folgen enthalten. Abschließend sollte darin eine Liste möglicher Gegenmaßnahmen enthalten sein.

Definition von Verantwortlichkeiten

Wachsende IT-Infrastrukturen werden schnell unübersichtlich. Es genügt nicht, die technischen Daten festzuhalten, denn im Notfall geht es auch (und vor allem) um mit den Prozessen und Schnittstellen vertraute Personen. Am Anfang stehen aber sicherlich die vollständige Erfassung der IT-Systeme und deren Komponenten.
Im nächsten Schritt wird diese Dokumentation durch die Zuweisung von Personen als Matrix ausgebaut. „Wer übernimmt  Verantwortung für was?“ ist die Frage dieser Entwurfsphase. Meist sind es nicht einzelne Personen, die hier als verantwortlich für die Wiederherstellung zeichnen. Meist sind es mehrere Mitarbeiter in Kombination mit Herstellern und Supportverträgen. Die dabei notwendigen Workflow-Pläne kann nur eine gut dokumentierte und intern organisierte Verantwortungsstelle leisten. Verantwortung also nicht nur für Systeme, sondern auch für Personen. Notfallmanagement will geplant sein.

Ein weiterer Punkt in diesem Zusammenhang ist die Erreichbarkeit und Verfügbarkeit von Ansprechpartnern, Supportmitarbeitern und Servicepartner. Dies gilt sowohl für interne (Urlaubs- und Krankheitsvertretung) wie auch externe Ressourcen. Wo war nochmal die Hotline-Nummer für den Wartungsvertrag – oder gar der Vertrag selbst? In der Praxis sollte dies zumindest einmal durchgespielt werden. Oder hat Ihr EDV-Leiter auch brav alles in seinem Outlook-Archiv abgelegt?

Vergessen Sie nicht die eigenen Mitarbeiter!

Sind Ihre Sicherungsbänder ausgelagert? Oder eventuell zusätzlich im hitzefesten Stahlschrank verwahrt? Was nutzen die besten Vorkehrungen, wenn die einzige Person, die darüber Auskunft geben kann, gerade den ersehnten Sahara-Trip absolviert. Ja, auch Herr Mustermann weiß Bescheid. Der kommt aber erst abends von der Alm zurück…
Hier helfen nur eine klare Zielsetzung, die ebenso klare Festlegung von Maßnahmen und die Organisation eines Notfallmanagements. Und nicht vergessen: Ihr EDV-System verändert sich ständig. Wenn der Notfallplan nicht „mitlebt“, ist er wertlos. Ein schlechter, weil nicht aktueller Notfallplan ist genauso schlimm wie ein fehlender.

Die richtige DR-Lösung

RPO und RTO sind die entscheidenden Kürzel in der Wahl des adäquaten DR-Systems. RPO (Recovery Point Objective) bestimmt den maximal akzeptierten Datenverlust im Katastrophenfall. Beispiel: Sie sichern Ihre Systeme jede Nacht. Wenn um 14:00 das wichtigste System den Lebensgeist aufgibt, bleibt ein (unwiederbringlicher) Datenverlust von mindestens 10 Stunden. Ist dies vertretbar? Für manche Systeme vielleicht schon, für einen Online-Shop ein Todesurteil.
Recovery Time Object (RTO) definiert die gewünschte Zeit für eine Wiederherstellung der Funktionsfähigkeit eines Systems oder einer Applikation. Dabei ist nicht nur die benötigte Zeit für das Recovery in Betracht zu ziehen, sondern der gesamte Zeitraum vom Ausfall bis zur Wiederaufnahme der Arbeit. Was nutzt es, wenn die Wiederherstellung der Datenbank in wenigen Stunden zu machen ist, aber die passende Ersatzhardware drei Tage Lieferzeit hat. Sowohl RPO wie auch RTO sind unmittelbar entscheidend für die Wahl der passenden DR-Lösung. Die Kosten steigen aber mit steigenden Ansprüchen exponentiell.

Der Desaster-Recovery-Leitfaden

Der beste DR-Plan nutzt nichts, wenn dieser nicht kommuniziert und sicher abgelegt ist. Die darin festgelegten Richtlinien und Prozeduren sollten getestet werden. Die daraus resultierenden Schwachstellen können damit noch vor dem Ernstfall einer Überarbeitung unterzogen und offene „Baustellen“ mit effizienten Handlungsanweisungen gefüllt werden. Der beste Plan ist aber nutzlos, wenn er nicht zur rechten Zeit greifbar ist. Neben einer praxiserprobten Stellvertreterregelung gehört dazu ebenso die Lagerung (eines Duplikats) an einem sicheren Ort.

Der Praxistest

Neben einem regelmäßigen Review gehört auch die Durchführung von Ausfallsimulationen zur vorbereitenden Praxistest. Erst die (gestellte) Katastrophe vor Augen bringt das entscheidende Maß an Realitätsbezug in den DR-Plan. Die nachfolgende Überarbeitung garantiert sowohl Aktualität wie auch Verbesserung. Dabei sollte der Test nicht nur den Ausfall eines Systems nachstellen, sondern auch die Fehlfunktion einer gesamten Anwendung (systemübergreifend). Ein erhöhter Sicherungsintervall war schon oft eine einfache aber ganz entscheidende Konsequenz.

Der entscheidende Fokus

Es geht nicht um Backup von Systemen. Erst die ganzheitliche Analyse von unternehmenskritischen Prozessen und Arbeitsabläufen kann die Abhängigkeit von einzelnen Komponenten richtig einschätzen und damit eine wirksame Desaster-Recovery-Prozedur ermöglichen. Und sollten Sie Ihren perfekten DR-Plan jahrelang „umsonst“ gepflegt haben – ärgern Sie sich nicht. Sie sind ja auch nicht böse, dass Ihr Haus nicht abgebrannt ist, obwohl Sie seit Jahren für eine Brandschutzversicherung zahlen.