Andrii - stock.adobe.com

So vermeiden Sie einen fehlerhaften Disaster-Recovery-Plan

Ausfälle zu vermeiden, ist Ziel des DR-Teams, aber Katastrophen richten sich nicht danach, wie Pläne entworfen werden. Sie müssen Ausfallursachen kennen, um den DR-Plan zu entwerfen.

IT-Teams, die einen Technologie-Disaster-Recovery-Plan umsetzen, hoffen, dass sie ihn nie anwenden müssen. Wenn jedoch ein Disaster-Recovery-Plan (DR-Plan) nie in einer Krise durchgespielt wird, kann dies bedeuten, dass die Strategie nicht getestet wurde und der Plan möglicherweise scheitert. Kein Unternehmen möchte mit einer Störung konfrontiert werden, aber IT-Teams dürfen nicht überrascht sein, wenn eine solche eintritt.

Die Unvorhersehbarkeit von Bedrohungen wie Ransomware und Naturkatastrophen bedeutet, dass sie jederzeit stattfinden können, selbst wenn ein Unternehmen sich noch nie mit ihnen befasst hat. Wenn es nie zu einer größeren Störung der IT-Infrastruktur kommt oder entsprechen reelle Tests durchgeführt werden, kann die Firma nicht mit Sicherheit wissen, ob ihr Plan funktionieren wird.

Um die Bedeutung eines getesteten DR-Plans zu verstehen, müssen IT-Teams die Ursachen für das Scheitern einer solchen Planung kennen. Neben einer Anleitung zur Erstellung eines DR-Plans finden Sie im Folgenden 13 häufige Gründe, warum ein Plan scheitern könnte, und wie Sie diese vermeiden können.

Bedeutung der Erstellung eines DR-Plans

Die meisten IT-Organisationen sind sich zwar darüber im Klaren, dass ein DR-Plan in einem Notfall hilfreich sein kann, können jedoch nie ganz sicher sein, ob er im Bedarfsfall funktioniert oder ob die Systeme und Mitarbeiter wie vorgesehen funktionieren werden.

Die DR-Planung zielt darauf ab, sicherzustellen, dass die Elemente der IT-Infrastruktur – einschließlich Hardware, Software, Netzwerkdienste, Umweltsysteme, physische Sicherheit, Cybersicherheit, Versorgungsdienste und Mitarbeiter – vor einem Störfall geschützt sind. Wenn diese kritischen Elemente durch eine DR-Strategie angemessen geschützt sind, können sie anschließend zu früheren Betriebsabläufen zurückkehren.

In einem Rechenzentrum befasst sich das Disaster Recovery in der Regel mit mehreren Elementen, darunter:

  • Backup, Recovery, Austausch und Wiederherstellung von Hardwaregeräten.
  • Backup, Recovery und Wiederaufbau von Netzwerkdiensten.
  • Backup, Recovery und Wiederaufbau von Systemen sowie Abruf von Daten.
  • Recovery und Wiederaufbau der vom Rechenzentrum genutzten physischen Einrichtungen.
  • Recovery und Wiederaufbau von Versorgungsleistungen wie Strom und Wasser.
  • Rückkehr des IT-Personals und Wiederaufnahme seiner vorherigen Aufgaben.

In der Praxis können die oben genannten Aspekte durch einen einzigen DR-Plan angegangen werden. IT-Teams können auch individuelle Pläne für bestimmte geschäftskritische Ressourcen entwickeln. Die erstgenannte Option beschreibt, wie IT-Abläufe auf hoher Ebene wiederhergestellt werden können, während individuelle Pläne auf die Details der Wiederherstellung, des Neustarts, des Testens und der Validierung von Ressourcen eingehen, bevor diese wieder in den Produktionsstatus versetzt werden.

Kurz gesagt beschreibt der allgemeine Plan die Verfahren zur Wiederherstellung und zum Wiederaufbau des IT-Betriebs und geht davon aus, dass die praktischen Details von Fachexperten innerhalb der IT-Abteilung adressiert werden. Theoretisch sollte dieser Ansatz funktionieren, es sei denn, der Vorfall tritt außerhalb der Szenarien auf, die als Teil des allgemeinen DR-Plans dargestellt werden.

Was passiert, wenn der DR-Plan fehlschlägt?

Beim Erstellen von DR-Plänen ist es wichtig, einen ganzheitlichen Ansatz zu verfolgen und dabei potenzielle Störfälle zu berücksichtigen. Dadurch steigt die Wahrscheinlichkeit, dass die in den Plänen beschriebenen Verfahren wie erforderlich funktionieren – oder zumindest dazu beitragen, die Schwere des Vorfalls zu mindern.

Aber was ist, wenn die oben genannten DR-Planungs- und Wiederherstellungsinitiativen nicht wie erwartet funktionieren?

Erstens müssen IT-Teams bei der Entwicklung von Plänen das Problem des Scheiterns von DR-Plänen berücksichtigen. Nehmen wir zum Beispiel an, die Strategie zum Schutz von Servern besteht darin, ein Inventar von Geräten bereitzuhalten, um beschädigte Einheiten ersetzen zu können. Wann wurden die Ersatzserver das letzte Mal getestet? Wenn die Backup-Server aus irgendeinem Grund nicht funktionieren, ist die Wiederherstellung gefährdet. Dasselbe gilt für wichtige Geschäftssysteme. Wenn die Backup-Anwendung nicht verfügbar ist oder nicht rechtzeitig beschafft werden kann, kann dies negative Auswirkungen auf das Geschäft und den Ruf des Unternehmens haben.

Was kann zum Scheitern eines DR-Plans führen?

Idealerweise identifizieren IT-Teams in der Phase der Planentwicklung die Risiken und Bedrohungen für wichtige Ressourcen sowie die Auswirkungen auf das Unternehmen, wenn diese Ressourcen deaktiviert werden. Aktivitäten in dieser Phase, wie zum Beispiel Risikobewertungen und Analysen der Auswirkungen auf das Unternehmen, können wichtige Daten für die Planentwicklung liefern und dazu beitragen, potenzielle Fehler zu vermeiden. Diese Analysen und Bewertungen können auch die Prioritäten für die Wiederherstellung und Wiederherstellung von Ressourcen ermitteln und so eine reibungslose und geordnete Wiederherstellung ermöglichen.

In Anbetracht der oben genannten Aspekte bei der Entwicklung und Umsetzung von DR-Plänen sind die folgenden 13 Gründe häufig dafür verantwortlich, dass ein DR-Plan scheitert. Jeder dieser Gründe ist ein Element des gesamten DR-Planungsprozesses.

  1. Mangelnde Unterstützung und Finanzierung durch die Geschäftsleitung. Dies ist oft der wichtigste Aspekt des Prozesses, da die Entwicklung von DR-Plänen durch mangelnde Unterstützung und Finanzierung durch das Management eingeschränkt werden kann. Dies kann dazu führen, dass eine Organisation einen Plan überhaupt nicht umsetzt oder einen unvollständigen Plan hat.
  2. Nicht die richtigen Personen in den Planungsprozess einbeziehen. Das DR-Team besteht in der Regel aus IT-Mitarbeitern und sollte auch Mitarbeiter umfassen, die die Gesamtverantwortung für den DR-Prozess tragen. Auch externe Experten können Teil des Teams sein.
  3. Technische Probleme. Technische Probleme, wie zum Beispiel Softwareprobleme oder unzureichende Backups, sind ein häufiger Grund für das Scheitern eines DR-Plans. IT-Teams müssen ausreichende Recherchen und Analysen durchführen, um die kostengünstigsten Lösungen für Probleme bei der Wiederherstellung der Technologie zu ermitteln. Sie sollten auch wissen, wann diese Elemente aktualisiert oder ersetzt werden müssen.
  4. Versäumnis, Pläne regelmäßig zu testen. Tests sind eine wichtige Maßnahme, da sie bestätigen, dass die im Plan definierten Verfahren wie vorgesehen funktionieren. Außerdem werden potenzielle Fehlerquellen identifiziert, bevor sie sich auf eine tatsächliche Wiederherstellung auswirken können.
  5. Es wird versäumt, eine Überprüfung nach dem Test durchzuführen und den Plan auf der Grundlage des Tests zu aktualisieren. Sobald ein Test abgeschlossen ist, besteht der nächste Schritt darin, zu überprüfen, was funktioniert hat und was nicht. IT-Teams müssen Pläne aktualisieren, um die gewonnenen Erkenntnisse widerzuspiegeln, und wenn möglich Folgetests durchführen, um die Änderungen zu validieren.
  6. Der Plan wird nicht im gesamten Unternehmen kommuniziert. Die Mitarbeiter müssen wissen, dass es Programme gibt, die den unterbrechungsfreien Betrieb der von ihnen genutzten IT-Ressourcen sicherstellen, und sie müssen wissen, was sie tun sollten, wenn ein Störfall eintritt.
  7. Unzureichende Schulung des DR-Teams. Das Wissen darüber, wie betroffene Ressourcen wiederhergestellt werden können – unabhängig davon, ob intern oder extern implementiert – muss durch Schulungen vermittelt und regelmäßig aufgefrischt werden, um sicherzustellen, dass die DR-Teams auf Notfälle vorbereitet sind.
  8. Mangelnde Mitarbeiterschulung für einen DR-Fall. Zusätzlich zur Sensibilisierung der Mitarbeiter für DR-Aktivitäten wird eine regelmäßige Schulung empfohlen, damit die Mitarbeiter wissen, was zu tun ist, wenn eine technologische Störung auftritt.
  9. Systemänderungen, die sich nicht in einem überarbeiteten DR-Plan widerspiegeln. Wenn Änderungen an geschäftskritischen Systemen und Ressourcen vorgenommen werden, müssen diese in DR-Plänen berücksichtigt werden, insbesondere wenn sich die Verfahren für die Wiederherstellung und die Wiederaufnahme des Betriebs/Geschäfts ändern.
  10. Fehlende regelmäßige Patches für geschäftskritische Systeme. Wenn Patches nicht regelmäßig installiert werden, kann dies zu unbeabsichtigten Systemunterbrechungen führen. Wenn beispielsweise Patches für Cybersicherheitssysteme nicht installiert werden, kann dies zu unbemerkten Malware-Angriffen führen.
  11. DR-Aktivitäten werden nicht in IT-Mitarbeiterbesprechungen einbezogen. Wenn DR keine regelmäßige Aktivität ist, kann sie leicht vergessen werden. Es ist ratsam, DR-Tagesordnungspunkte in IT-Mitarbeiterbesprechungen aufzunehmen.
  12. Versäumnis, den Plan und die damit verbundenen Aktivitäten zu überprüfen und zu bewerten. Zusätzlich zu Live-Systemtests empfiehlt es sich, DR-Pläne – aller Art – regelmäßig zu überprüfen und zu bewerten, um sicherzustellen, dass sie aktuell und umsetzbar sind.
  13. Es wird nicht definiert, was ein fehlerhafter Plan ist. Es ist wichtig festzulegen, was bei der DR-Planung als Scheitern gilt, damit die Schlüsselelemente richtig angegangen werden und der Plan regelmäßig getestet wird.

Die Durchführung der oben genannten Schritte kann dazu beitragen, die Wahrscheinlichkeit zu verringern, dass DR-Pläne im Notfall scheitern.

Erfahren Sie mehr über Disaster Recovery