Guido Vrola - Fotolia
6 Tipps für die Problemvermeidung bei Disaster Recovery
Für ein erfolgreiches Disaster Recovery gibt es einige Risiken zu bedenken, wie verpasste Planung, nicht durchgeführte Tests, schlechte Kommunikation oder schlechter Backup-Schutz.
Unter Disaster Recovery (DR) versteht man die Fähigkeit, nach einem IT-Ausfall, einer Naturkatastrophe oder einem anderen unerwarteten Ereignis zum normalen Geschäftsbetrieb (Business as usual) zurückzukehren, und ist eine Schlüsselfunktion der IT.
Schließlich ist die IT-Abteilung verantwortlich für die Wartung der Kerngeschäftssysteme und den Schutz ihrer Daten, für die Bereitstellung von Desktop- oder anderen Personalcomputern, Netzwerken und – heute häufiger als früher – für die Sprachkommunikation.
Doch die Disaster-Recovery-Planung ist eine unternehmensweite Herausforderung und Verantwortung. Organisationen sind immer mehr von ihren Daten abhängig, und die IT-Abteilung wird immer geschickter darin, den Zugriff auf diese Daten überall auf der Welt zu ermöglichen.
Dagegen müssen IT-Abteilungen mit immer größeren Datenmengen umgehen, ebenso wie mit Benutzern und Kunden, die Ausfallzeiten weniger tolerant gegenüber stehen, und einer wachsenden Zahl von kriminellen Akteuren, die den Angriff auf Daten als eine Möglichkeit sehen, Organisationen aus finanziellen Gründen zu Fall zu bringen.
Der internationale Standard für Geschäftskontinuität (Business Continuity), ISO 27031, legt einen Rahmen für die Disaster-Recovery-Pläne von Organisationen fest.
Doch angesichts der zunehmenden Komplexität sowohl der Geschäftsabläufe als auch der IT-Systeme gibt es viele Fällen für die Unvorsichtigen.
DR-Falle 1: Planversäumnis
Das größte Versäumnis besteht darin, überhaupt nicht für die Wiederherstellung im Katastrophenfall zu planen.
Ein DR-Plan muss nicht komplex sein. Im Falle eines kleinen Unternehmens oder einer Zweigstelle könnte er kaum mehr als regelmäßige Backups auf Datenträger, die außerhalb des Unternehmens oder zunehmend in der Cloud gespeichert sind, und einen Plan für den Zugriff auf die Daten und die Wiederherstellung von Anwendungen im schlimmsten Fall umfassen.
Für größere Organisationen wird ein Plan sehr viel detaillierter darauf eingehen, welche Anwendungen geschützt sind, wie sie wiederhergestellt werden und Vorkehrungen für alternative Arbeitsbereiche für die Mitarbeiter treffen.
Tony Lock, ein Analyst bei Freeform Dynamics, betont, dass in einem Plan angegeben werden sollte, in welcher Reihenfolge die verschiedenen Plattformen wiederhergestellt werden müssen. „Manchmal ist dies aufgrund von Anwendungs- oder Serviceanforderungen offensichtlich, aber wenn eine größere Standortwiederherstellung erforderlich ist, kann auch die interne Politik ins Spiel kommen“, sagt er. Es stellt sich auch die Frage, wer eine DR-Aktion initiieren kann und unter welchen Umständen.
Weitere Probleme treten auf, wenn Organisationen über einen DR-Plan verfügen, dieser aber in seinem Umfang zu begrenzt ist. Hier können sich IT und Vorstand in einem falschen Sicherheitsgefühl wiegen. In solchen Fällen gibt es zwar einen DR-Plan, aber er deckt nicht alle Anwendungen und, ganz entscheidend, deren Abhängigkeiten untereinander ab.
„Nur etwa 38 Prozent der Anwendungen sind durch einen DR-Plan geschützt“, mahnt Phil Goodwin, Analyst bei IDC. „Die meisten Organisationen bieten DR für unternehmenskritische Anwendungen an, gehen dann aber zu anderen Projekten über. Das Ergebnis ist oft, dass diesen unternehmenskritischen Anwendungen Daten fehlen oder Verbindungen zu weniger kritischen Anwendungen bestehen. Und die gesamte Umgebung kann nicht schnell genug aufrechterhalten werden.“
Der Plan muss auch die Recovery Point Objective (RPO) und Recovery Time Objective (RTO) festlegen – also wie weit die Organisation zurückgehen muss, um einen sauberen und stabilen Satz von Anwendungen und Daten zu erhalten, und wie schnell das geschehen muss.
DR-Falle 2: Keine Tests
Die nächste und vielleicht größte Falle ist das Scheitern oder Fehlen eines Tests. Eine häufig zitierte Statistik besagt, dass 23 Prozent der Organisationen ihre DR-Pläne nie testen, weitere 29 Prozent testen nur einmal im Jahr.
Ob ein jährlicher Test angemessen ist, hängt sehr stark von der Größe und Art des Unternehmens ab. Aber ein Plan, der nie getestet wird, ist eigentlich nur ein Schritt weiter, als wenn man überhaupt keinen Plan hätte.
„Das andere große Problem betrifft das Testen von Disaster-Recovery-Prozessen“, sagt Freeform Dynamics Lock. „Dies ist von wesentlicher Bedeutung, denn bis man DR testet, kann man nicht wirklich sicher sein, dass es funktioniert, oder ob alle Systeme, die hätten geschützt werden sollen, es auch wirklich sind.“
Die Gewährleistung eines robusten Testregimes erfordert eine starke Führung durch den CIO. Effektive DR-Tests können störend und teuer sein. Aber wenn es nicht gelingt, sich von einer Katastrophe zu erholen, wird es noch teurer.
„Das Problem kann darin bestehen, dass entweder Geschäftsanwender oder Budgetverantwortliche zögern, Tests zuzulassen“, warnt Lock. Deshalb ist ein starkes Eintreten der IT-Führungskräfte so wichtig.
Eng verbunden mit dem Versäumnis, den DR-Plan zu testen, ist das Versäumnis, ihn zu aktualisieren. Ein DR-Plan ist ein lebendes Dokument. Wenn sich das Unternehmen durch Wachstum, Übernahmen, Geschäftsprozessänderungen oder Technologie-Updates verändert, ändern sich auch die DR-Anforderungen und -Methoden. Ein detaillierter Plan, der auf einem Regal steht, wird nicht effektiv sein.
Wenn die Organisation den Plan testet, müssen die CIOs sicherstellen, dass alle daraus gezogenen Lehren – und es wird Lehren geben – zur Aktualisierung des Plans genutzt werden. Der aktualisierte Plan muss getestet werden, und der Zyklus muss wiederholt werden.
DR-Falle 3: Backups nicht ausreichend schützen
Malware, und insbesondere Ransomware, ist einer der Gründe dafür, dass DR in den letzten Jahren wieder auf der Tagesordnung nach oben gerückt ist.
Insbesondere der Schutz von Systemen vor Lösegeldforderungen beziehungsweise Ransomware-Attacken bedeutet, dass zwischen Produktionssystemen und Sicherungskopien eine Luftlücke (Medienbruch) geschaffen oder unveränderliche Speichertechnologien eingesetzt werden müssen, nicht zuletzt, weil die Angreifer gelernt haben, Backups zuerst ins Visier zu nehmen.
Einige Organisationen sind zu Tape-Lösungen als relativ kostengünstige Möglichkeit zurückgekehrt, um Daten an einen anderen Standort zu verlagern.
Leider ist dies für DR-Teams nicht immer einfach. Business-Continuity-Pläne und -Ziele für kürzere RTOs hängen von einer kontinuierlichen Data Protection ab.
„Aber man kann nicht auf kontinuierlicher Basis diese Lücke aufrecht erhalten“, warnt IDCs Goodwin. Stattdessen müssen Unternehmen möglicherweise 12-24 Stunden Datenverlust als Preis für saubere Daten akzeptieren.
DR-Falle 4: Befehls-, Kontroll- und Kommunikationsprobleme
In einer Katastrophensituation sind klare Kommunikationslinien und eine klare Vorstellung davon, wer die Kontrolle hat, von entscheidender Bedeutung.
Organisationen müssen auch entscheiden, wer sich auf den DR-Plan berufen kann, und sicherstellen, dass alle Schlüsselmitarbeiter während eines Ausfalls weiterhin kommunizieren können. Ein robuster DR-Test wird in der Regel alle Fehler in der Führung und Kontrolle aufdecken, und bei größeren Unternehmen sollte die Krisenkommunikation Teil des Plans sein.
Aber es besteht auch ein Bedarf an kontinuierlicher Kommunikation rund um DR und Business Continuity.
„Die Anwender haben eine vielleicht unrealistische Erwartung einer sofortigen Wiederherstellung für alles, und es kann leicht passieren, dass bei steigendem Druck etwas schief geht“, sagt Lock.
Eine klare Kommunikation wird dazu beitragen, die Erwartungen darüber zu managen, welche Daten und Systeme in welcher Reihenfolge und wie schnell wiederhergestellt werden können, fügt IDCs Goodwin hinzu.
DR-Falle 5: Vernachlässigung menschlicher Faktoren
IT-Abteilungen konzentrieren ihre DR-Planung naturgemäß auf Systeme und Daten. Effektive Pläne müssen aber auch abdecken, wo und wie die Mitarbeiter arbeiten werden, wenn der Hauptgeschäftssitz gefährdet ist.
Es mag sein, dass die Mitarbeiter zunächst von zu Hause aus arbeiten können, aber wie lange können sie das durchhalten?
Benötigen einige Mitarbeiter Desktop-Computer oder mehr Bandbreite, als häusliche oder mobile Verbindungen bieten können? Wie sieht es mit Besprechungsräumen aus, und wie steht es um das körperliche und geistige Wohlbefinden des Teams? Die Aufrechterhaltung der Moral im Falle einer Katastrophe ist oft genauso wichtig wie die technischen Aspekte des Wiederherstellungsplans.
DR-Falle 6: Die Cloud vernachlässigen
Cloud Computing macht einige Aspekte der Notfallwiederherstellung sehr viel einfacher, insbesondere mit dem Wachstum von Online-Backup-Diensten.
Aber die Cloud kann die Komplexität des IT-Betriebs erhöhen, insbesondere in Hybrid- und Multi-Cloud-Umgebungen.
Außerdem besteht für die Geschäftsbereiche die Möglichkeit, ihre eigenen Cloud-Ressourcen aufzustocken oder SaaS-Anwendungen (Software as a Service) zu kaufen, was bedeutet, dass die IT-Abteilung möglicherweise keinen vollständigen Überblick mehr über die IT-Infrastruktur des Unternehmens hat. Und sieht der Plan vor, was zu tun ist, wenn ein Cloud-Service ausfällt?
Untersuchungen von Spiceworks haben ergeben, dass nur 28 Prozent der Unternehmen Cloud- oder Hosted Services in ihre DR-Pläne aufgenommen haben. Und es reicht nicht aus, sich auf die Backup- und Business-Continuity-Pläne des Cloud-Anbieters zu verlassen.
Es kann sein, dass der Cloud-Anbieter wenig tun kann, beispielsweise wenn ein Benutzer versehentlich Daten löscht.
Und ein teilweiser Ausfall – beispielsweise eines Datenspeichers vor Ort, der eine Cloud-basierte Anwendung bedient – kann schwieriger zu beheben sein als ein herkömmlicher Stack, bei dem sich die Daten und Anwendungen am selben Ort befinden.
Aber auch bei Wiederherstellungsplänen für Cloud-Infrastrukturen sollten gründliche Tests etwaige Schwächen aufdecken.