Disaster-Recovery (DR) umfasst IT-Technologien und bewährte Verfahren zur Vermeidung oder Minimierung von Datenverlusten und Betriebsunterbrechungen infolge von Katastrophenereignissen – von Geräteausfällen und lokalen Stromausfällen bis hin zu Cyberattacken, zivilen Notfällen, kriminellen oder militärischen Angriffen und Naturkatastrophen.

Viele Unternehmen – insbesondere kleine und mittelständische Organisationen – vernachlässigen die Entwicklung eines zuverlässigen und praktikablen Disaster-Recovery-Plans. Ohne einen solchen Plan sind sie kaum vor den Auswirkungen von Ereignissen geschützt, die mit erheblichen Störungen einhergehen.

Ein Ausfall der Infrastruktur kann bis zu 100.000 US-Dollar pro Stunde kosten (Link befindet sich außerhalb von IBM) und die Kosten für den Ausfall kritischer Anwendungen können zwischen 500.000 und 1 Million US-Dollar pro Stunde liegen. Viele Unternehmen sind nicht in der Lage, sich von derartigen Verlusten zu erholen. Mehr als 40 % der kleinen Unternehmen nehmen nach einer Katastrophe ihren Betrieb nicht wieder auf und von denjenigen, die es doch tun, scheitern weitere 25 % innerhalb des ersten Jahres nach der Krise. Eine Disaster-Recovery-Planung kann diese Risiken deutlich reduzieren.

Die Disaster-Recovery-Planung umfasst das Entwickeln einer Strategie, Planung, den Einsatz einer geeigneten Technologie und kontinuierliche Tests. Das Erstellen von Sicherungskopien Ihrer Daten ist eine wichtige Komponente der Disaster-Recovery-Planung, aber ein Sicherungs- und Wiederherstellungsprozess allein macht noch keinen vollständigen Disaster-Recovery-Plan aus.

Bei der Disaster-Recovery muss auch sichergestellt werden, dass ausreichende Speicher- und Rechenkapazitäten zur Verfügung stehen, um zuverlässige Failover- und Failback-Verfahren zu ermöglichen. Failover ist der Prozess der Auslagerung von Workloads auf Backup-Systeme, damit Produktionsprozesse und Endbenutzererlebnisse so wenig wie möglich beeinträchtigt werden. Failback bedeutet, dass zu den ursprünglichen Primärsystemen zurückgewechselt wird.

Lesen Sie den Artikel, um mehr zu dem wichtigen Unterschied zwischen Backup- und Disaster-Recovery-Planung zu erfahren.

Durch die Business-Continuity-Planung werden Systeme und Prozesse geschaffen, die sicherstellen, dass alle Bereiche Ihres Unternehmens in der Lage sind, im Falle einer Krise oder eines Notfalls die wesentlichen Abläufe aufrechtzuerhalten oder so schnell wie möglich wiederaufzunehmen. Die Disaster-Recovery-Planung ist der Teilbereich der Business-Continuity-Planung, der sich auf die Wiederherstellung der IT-Infrastruktur und -Systeme konzentriert.

Business-Impact-Analyse

Das Erstellen eines umfassenden Disaster-Recovery-Plans beginnt mit einer Analyse der Auswirkungen auf das Unternehmen (Business-Impact-Analyse). Bei der Durchführung dieser Analyse erstellen Sie eine Reihe detaillierter Katastrophenszenarien, anhand derer Sie die Größe und den Umfang der Verluste vorhersagen können, die Ihnen bei einer Unterbrechung bestimmter Geschäftsprozesse entstehen würden. Was wäre zum Beispiel, wenn das Call-Center Ihres Kundenservice durch ein Feuer zerstört würde? Oder wenn es an Ihrem Unternehmenssitz ein Erdbeben gäbe?

Auf diese Weise können Sie die kritischsten Bereiche und Funktionen des Unternehmens ermitteln und bestimmen, wie viel Ausfallzeit jede dieser kritischen Funktionen verkraften kann. Mit diesen Informationen können Sie einen Plan erstellen, wie die kritischsten Abläufe in verschiedenen Szenarien aufrechterhalten werden können.

Die IT-Disaster-Recovery-Planung sollte sich an die Business-Continuity-Planung anschließen und diese unterstützen. Wenn Ihr Business-Continuity-Plan beispielsweise vorsieht, dass Kundenservicemitarbeiter nach einem Brand in einem Call-Center von zu Hause aus arbeiten sollen – welche Hardware, Software und IT-Ressourcen müssten dann zur Unterstützung dieses Plans zur Verfügung stehen?

Risikoanalyse

Die Bewertung der Wahrscheinlichkeit und der potenziellen Folgen der Risiken, denen Ihr Unternehmen ausgesetzt ist, ist ebenfalls ein wesentlicher Bestandteil der Disaster-Recovery-Planung. Angesichts der zunehmenden Verbreitung von Cyberangriffen und Ransomware ist es von entscheidender Bedeutung, die allgemeinen Cybersicherheitsrisiken zu verstehen, mit denen alle Unternehmen heute konfrontiert sind, sowie die Risiken, die für Ihre Branche und Ihren Standort spezifisch sind.

Für eine Vielzahl von Szenarien, darunter Naturkatastrophen, Geräteausfälle, Insiderbedrohungen, Sabotage und Mitarbeiterfehler, müssen Sie Ihre Risiken bewerten und die Gesamtauswirkungen auf Ihr Unternehmen abschätzen. Stellen Sie sich die folgenden Fragen:

• Welche finanziellen Verluste aufgrund verpasster Verkaufschancen oder Unterbrechungen von umsatzwirksamen Aktivitäten würden für Ihr Unternehmen entstehen?
  
  
• Welchen Imageschaden würde Ihre Marke erleiden? Wie würde sich das auf die Kundenzufriedenheit auswirken?
  
  
• Welche Auswirkungen hätte das auf die Produktivität der Mitarbeiter? Wie viele Arbeitsstunden würden gegebenenfalls verloren gehen?
  
  
• Welche Gesundheits- und/oder Sicherheitsrisiken könnte der Vorfall mit sich bringen?
  
  
• Würden Fortschritte bei Geschäftsinitiativen oder -zielen beeinträchtigt? Wie?

Priorisierung von Anwendungen

Nicht alle Workloads sind gleich wichtig für die Aufrechterhaltung des Geschäftsbetriebs, und bei einigen Anwendungen sind Ausfallzeiten weitaus leichter zu verkraften als bei anderen. Klassifizieren Sie Ihre Systeme und Anwendungen in drei Stufen, je nachdem, wie lange Sie einen Ausfall verkraften können und wie schwerwiegend die Folgen eines Datenverlusts wären.

1. Geschäftskritisch: Anwendungen, deren Funktionen für den Fortbestand Ihres Unternehmens unentbehrlich sind.
   
   
2. Wichtig: Anwendungen, bei denen relativ kurze Ausfallzeiten in Kauf genommen werden können.
   
   
3. Nicht wesentlich: Anwendungen, die Sie vorübergehend durch manuelle Prozesse ersetzen oder auf die Sie zeitweilig verzichten können.

Dokumentieren von Abhängigkeiten

Der nächste Schritt in der Disaster-Recovery-Planung ist eine vollständige Bestandsaufnahme Ihrer Hardware und Software. In diesem Stadium ist es wichtig, die kritischen Abhängigkeiten zwischen den Anwendungen zu klären. Wenn eine Softwareanwendung ausfällt – welche anderen sind dann betroffen?

Ausfallsicherheit und Disaster-Recovery-Modelle, die bereits bei der Entwicklung von Systemen berücksichtigt werden, sind der beste Weg, um die Abhängigkeiten zwischen Anwendungen zu beherrschen. In den heutigen, auf Microservices basierenden Architekturen kommt es nur allzu oft vor, dass Prozesse nicht gestartet werden können, weil andere Systeme oder Prozesse ausgefallen sind. Solche Probleme müssen unbedingt rechtzeitig aufgedeckt werden, damit Sie Alternativpläne für Ihre Systeme und Prozesse entwickeln können, bevor es zu einer tatsächlichen Katastrophe kommt.

Festlegen von Zielen für die Wiederherstellungszeit, den Wiederherstellungspunkt und die Wiederherstellungskonsistenz

Anhand Ihrer Risiko- und Auswirkungsanalysen sollten Sie in der Lage sein, Ziele dafür festzulegen, wie lange die Wiederherstellung der Systeme dauern darf, in welchem Umfang die Daten wiederhergestellt werden müssen und wie viele Inkonsistenzen Sie bei den Daten tolerieren können.

Ihr Ziel für die Wiederherstellungszeit (RTO, Recovery Time Objective) ist die maximale Zeitspanne, die für die Wiederherstellung der Anwendungs- oder Systemfunktion nach einer Serviceunterbrechung benötigt werden darf.

Ihr Ziel für den Wiederherstellungspunkt (Recovery Point Objective, RPO) ist das maximale Alter der Daten, die wiederhergestellt werden müssen, damit Ihr Unternehmen den regulären Betrieb wiederaufnehmen kann. Für einige Unternehmen kann der Verlust von Daten schon nach wenigen Minuten katastrophal sein, während andere Branchen längere Zeiträume verkraften können.

In der Service-Level-Vereinbarung (SLA) für kontinuierliche Datenschutzservices wird ein Ziel für die Wiederherstellungskonsistenz (Recovery Consistency Objective, RCO) festgelegt. Dabei handelt es sich um eine Metrik, die angibt, wie viele inkonsistente Einträge in Geschäftsdaten aus wiederhergestellten Prozessen oder Systemen in Disaster-Recovery-Situationen tolerierbar sind, und die die Integrität von Geschäftsdaten in komplexen Anwendungsumgebungen beschreibt.

Probleme mit der Einhaltung gesetzlicher Vorschriften

Die gesamte Disaster-Recovery-Software und die entsprechenden Lösungen, die Ihr Unternehmen eingeführt hat, müssen alle Datenschutz- und Sicherheitsanforderungen erfüllen, zu deren Einhaltung Sie verpflichtet sind. Das bedeutet, dass alle Backup- und Failover-Systeme so konzipiert sein müssen, dass sie dieselben Standards zur Gewährleistung der Vertraulichkeit und Integrität der Daten erfüllen wie Ihre Primärsysteme.

Gleichzeitig schreiben verschiedene gesetzliche Bestimmungen vor, dass alle Unternehmen Disaster-Recovery- und/oder Business-Continuity-Pläne unterhalten müssen. So verlangt beispielsweise der Sarbanes-Oxley Act (SOX) von allen börsennotierten Unternehmen in den USA, alle Geschäftsunterlagen für einen Zeitraum von mindestens fünf Jahren aufzubewahren. Die Nichteinhaltung dieser Vorschrift (darunter das Versäumnis, geeignete Datensicherungssysteme einzurichten und zu testen) kann erhebliche Geldstrafen für Unternehmen und sogar Gefängnisstrafen für deren Führungskräfte zur Folge haben.

Auswahl von Technologien

Backups bilden die Grundlage für jeden soliden Disaster-Recovery-Plan. In der Vergangenheit nutzten die meisten Unternehmen für Backups Bänder und Festplatten (HDD), wobei sie mehrere Kopien ihrer Daten aufbewahrten und mindestens eine an einem externen Standort speicherten.

In der heutigen, sich ständig wandelnden digitalen Welt können Bandsicherungen in externen Repositorys oft nicht die RTOs erreichen, die zur Aufrechterhaltung geschäftskritischer Abläufe erforderlich sind. Der Aufbau einer eigenen Disaster-Recovery-Lösung beinhaltet die Replikation vieler Funktionen Ihrer Produktionsumgebung und verursacht Kosten für Supportpersonal, Verwaltung, Einrichtungen und Infrastruktur. Aus diesem Grund greifen viele Unternehmen auf cloudbasierte Backup-Lösungen oder auf Anbieter von Disaster-Recovery as a Service (DRaaS) zurück.

Auswahl von Recovery-Standorten

Beim Aufbau eines eigenen Rechenzentrums für die Disaster-Recovery müssen mehrere konkurrierende Ziele miteinander in Einklang gebracht werden. Einerseits sollte eine Kopie Ihrer Daten an einem Ort gespeichert werden, der geografisch so weit von Ihrem Hauptsitz entfernt ist, dass er nicht von denselben seismischen Ereignissen, Umweltbedrohungen oder anderen Gefahren betroffen ist wie Ihr Hauptstandort. Andererseits dauert die Wiederherstellung von extern gespeicherten Backups immer länger als die Wiederherstellung von Backups, die sich am Hauptstandort befinden, und die Netzlatenz kann bei größeren Entfernungen noch größer sein.

Kontinuierliche Tests und Überprüfung

Einfach ausgedrückt: Wenn Ihr Disaster-Recovery-Plan nicht getestet wurde, kann man sich nicht auf ihn verlassen. Alle Mitarbeiter mit entsprechenden Zuständigkeiten sollten am Disaster-Recovery-Testlauf teilnehmen, der möglicherweise auch die Aufrechterhaltung des Betriebs vom Ausweichstandort für eine gewisse Zeit beinhaltet.

Wenn die Durchführung umfassender Disaster-Recovery-Tests Ihr Budget oder Ihre Möglichkeiten übersteigt, können Sie auch einen Durchlauf der Testverfahren als „Trockenübung“ planen. Sie sollten sich allerdings darüber im Klaren sein, dass diese Art von Test Anomalien oder Schwächen in Ihren DR-Verfahren mit geringerer Wahrscheinlichkeit sichtbar macht – insbesondere das Vorhandensein von bis dahin unentdeckten Anwendungsabhängigkeiten – als ein vollständiger Test.

Da sich Ihre Hardware- und Software-Assets im Laufe der Zeit ändern, sollten Sie sicherstellen, dass Ihr Disaster-Recovery-Plan ebenfalls aktualisiert wird. Sie sollten den Plan in regelmäßigen Abständen überprüfen und überarbeiten.

Das IBM Knowledge Center bietet ein Beispiel für einen Disaster-Recovery-Plan.

Disaster-Recovery as a Service (DRaaS) ist eines der gefragtesten und am schnellsten wachsenden Angebote für verwaltete IT-Services, die heute verfügbar sind. Ihr Anbieter dokumentiert die RTOs und RPOs in einer Service-Level-Vereinbarung (SLA), in der die maximalen Ausfallzeiten und die Erwartungen an die Wiederherstellung der Anwendung festgelegt sind.

DRaaS-Anbieter bieten in der Regel cloudbasierte Failover-Umgebungen an. Dieses Modell ermöglicht erhebliche Kosteneinsparungen im Vergleich zum Unterhalt redundanter dedizierter Hardwareressourcen in Ihrem eigenen Rechenzentrum. Sie können Verträge abschließen, in denen Sie eine Gebühr für die Aufrechterhaltung der Failover-Funktionen sowie die Kosten für die Nutzung der im Notfall verbrauchten Ressourcen zahlen. Ihr Anbieter übernimmt in der Regel die gesamte Verantwortung für die Konfiguration und Wartung der Failover-Umgebung.

Disaster-Recovery-Serviceangebote unterscheiden sich von Anbieter zu Anbieter. Einige Anbieter definieren ihr Angebot als umfassende All-in-one-Lösung, während andere einzelne Services anbieten, die von der Wiederherstellung einzelner Anwendungen bis zur vollständigen Replikation des Rechenzentrums in der Cloud reichen. Einige Angebote umfassen Services für Disaster-Recovery-Planung oder -Test, während andere eine zusätzliche Beratungsgebühr für diese Angebote verlangen.

Vergewissern Sie sich, dass alle im Unternehmen eingesetzten Softwareanwendungen unterstützt werden, ebenso wie alle Public Cloud-Anbieter, mit denen Sie zusammenarbeiten. Sie sollten außerdem sicherstellen, dass die Anwendungsleistung in der Failover-Umgebung ausreichend ist und dass die Failover- und Failback-Verfahren gut getestet wurden.

Wenn Sie bereits eine lokale Disaster-Recovery-Lösung (DR-Lösung) aufgebaut haben, kann es schwierig sein, die Kosten und Vorteile der Weiterverwendung dieser Lösung im Vergleich zu einem monatlichen DRaaS-Abonnement zu bewerten.

Bei den meisten DR-Lösungen vor Ort fallen Kosten für Hardware, Strom, Wartung und Verwaltung, Software und Netzverbindungen an. Zusätzlich zu den Vorabinvestitionen für die Ersteinrichtung Ihrer DR-Umgebung müssen Sie zudem regelmäßige Software-Upgrades einplanen. Da Ihre DR-Lösung mit Ihrer primären Produktionsumgebung kompatibel bleiben muss, sollten Sie sicherstellen, dass Ihre DR-Lösung über dieselben Softwareversionen verfügt. Je nach den Besonderheiten Ihrer Lizenzvereinbarung können sich Ihre Softwarekosten dadurch verdoppeln.

Die Umstellung auf ein DRaaS-Abonnement kann nicht nur Ihre Hardware- und Softwareausgaben reduzieren, sondern auch Ihre Arbeitskosten senken, da die Wartung des Failover-Standorts vom Anbieter übernommen wird.

Wenn Sie DRaaS-Lösungen von Drittanbietern in Erwägung ziehen, sollten Sie sicherstellen, dass der Anbieter über die Kapazität für regions- und standortübergreifende Backups verfügt. Wenn ein schwerwiegendes Wetterereignis wie ein Wirbelsturm Ihren Hauptstandort treffen würde – wäre der Failover-Standort dann weit genug entfernt, um nicht von dem Sturm betroffen zu sein? Würde der Anbieter über ausreichende Kapazitäten verfügen, um den Bedarf aller Kunden in Ihrem Gebiet zu decken, wenn viele Kunden gleichzeitig betroffen wären? Sie verlassen sich darauf, dass Ihr DRaaS-Anbieter die RTOs und RPOs in Krisenzeiten einhält. Deshalb sollten Sie sich nach einem Dienstleister umsehen, der für seine Zuverlässigkeit bekannt ist.

Lesen Sie den Artikel „Disaster Recovery as a Service (DRaaS) vs. Disaster Recovery (DR): Which Do You Need?“, um sich einen vergleichenden Überblick über die beiden Lösungen zu verschaffen.