filograph - Fotolia

Diese drei Schritte führen zu einem guten Cloud-Disaster-Recovery-Plan

Die Cloud kann bei Disaster Recovery eine wertvolle Rolle spielen. Wir zeigen, wie Sie mit richtiger Planung auf Ausfälle vorbereitet sein werden.

Disaster Recovery (DR) ist eine Herausforderung für Storage-Administratoren. Während andere IT-Bereiche mittlerweile einfacher zugänglich sind, ist DR in den letzten Jahren ständig komplexer und aufwendiger geworden.

Erstens wurde die Definition eines Desasters immer umfassender. Heute ist damit praktisch jede Betriebsunterbrechung gemeint. Zum zweiten gibt es zahlreiche Ursachen. Diese reichen von Naturkatastrophen bis hin zu Cyberattacken, Ransomware, Anwenderfehlern und Sabotage. Drittens sind die Datenmengen exponentiell gewachsen, die es zu schützen gilt. Und viertens erwarten die Nutzer heute immer schnellere Reaktionen der IT-Abteilung.

Dabei stagnieren die Budgets für Disaster Recovery (DR). Viele Unternehmen, egal ob klein oder groß, erwarten, dass ihr Cloud-Disaster-Recovery-Plan ihre Probleme löst und sie ihre DR-Ausgaben senken können.

Backup, Archiv und DR in der Cloud

Man sollte verstehen, für welche Data Protection Prozesse die Speicherung in der Cloud geeignet ist und für welche nicht. Die meisten dieser Prozesse haben drei Bestandteile, nämlich Backup, Archiv und Recovery. Betrachten wir diese drei Punkte im Einzelnen:

  1. Backup: Backup bedeutet das Kopieren von Daten mit dem Ziel, sie für eine Wiederherstellung bei einem Ausfall verfügbar zu halten. Die meisten Unternehmen bewahren Backup-Daten nur für eine begrenzte Zeit auf (normalerweise drei bis sieben Jahre). Bei einer Speicherung in der Cloud muss man die Kapazität einplanen, die ein tägliches Backup auf Jahre hin in Anspruch nimmt. Von der Datenmenge hängt es ab, ob die Speicherung in der Cloud wirklich kosteneffektiv ist oder nicht.
  2. Archiv: Bei einem Archiv geht es um die langfristige Aufbewahrung von Daten. Dies sollte der Ort sein, wo die finale Datenkopie gelagert wird, idealerweise an zwei Orten und in zwei unterschiedlichen Formaten. Je besser die Archivstrategie eines Unternehmens ist, desto kleiner wird die Menge der tatsächlich geschützten Daten sein und der Zeitraum, um diese wiederherzustellen. Die meisten Unternehmen müssen Archive mindestens sieben Jahre aufbewahren, teilweise viel länger. Cloud Storage für so viele Jahre anzumieten, ist nicht kosteneffektiv und die Cloud damit nicht der geeignete Speicherort für Archive.
  3. Recovery: Recovery, besonders Disaster Recovery, erfordert fast immer die jeweils neueste Datenkopie. Wenn ein anderer Zeitraum wiederhergestellt werden soll, kann ein Archiv als Quelle dienen. Die Cloud eignet sich gut für Recovery, weil dort nur die jeweils neue Datenkopie abgelegt werden muss und fast alle Provider im Katastrophenfall den Zugriff auf die eigenen Compute-Ressourcen erlauben. Dies erspart es, eigene Storage- und Server-Hardware an einem Zweitstandort verfügbar zu halten. Deswegen hat sich Disaster Recovery as a Service (DRaaS) zu einer idealen Methode entwickelt, um mit DR-Herausforderungen fertig zu werden.

Betrachten wir nun die Dinge, die bei einem Cloud-Disaster-Recovery-Plan zu berücksichtigen sind und wie man diesen schrittweise angehen sollte.

Schritt 1: Daten in die Cloud bringen

Der erste Schritt bei einem Cloud-DR-Plan ist der Transport der Daten zum Provider und die Optimierung der Kosten durch die Kontrolle, welche Daten dort gespeichert werden sollen. Das ist vorzugsweise nur die jeweils aktuelle Kopie.

Es gibt zahlreiche Optionen für die Speicherung von Daten. Grundsätzlich gibt es aber zwei Haupttypen, nämlich Produkte für Backup und für Replikation. Der Unterschied liegt darin, wie die Daten gelagert werden.

Die meisten Cloud-Backup-Produkte speichern Daten in einem proprietären Format. Im Katastrophenfall müssen diese Daten extrahiert und in ein Format konvertiert werden, mit denen die virtuellen Maschinen des Unternehmens etwas anfangen können.

Die meisten Anbieter für Cloud-Backup setzen auf eine Appliance im Rechenzentrum des Kunden, die die Daten erfasst und dann in die Cloud überträgt.

Im Gegensatz dazu setzen die Anbieter von Replikation auf native Formate, auf die sofort zugegriffen werden kann, wenn das primäre Rechenzentrum ausfällt. Die Kunden haben die Wahl, ob sie auf Hochleistungs-Cloud-Storage zugreifen wollen, um die Wiederherstellung noch schneller zu machen.

In beiden Fällen gibt es eine Herausforderung bei der anfänglichen Datenübertragung. Es kann Stunden oder gar Wochen dauern, um die Daten in die Cloud zu übertragen, die als Grundlage für Backup oder Replikation dienen.

Um diesen Prozess zu beschleunigen, installieren einige Provider ein Hochleistungs-NAS beim Kunden. Die Grunddaten werden auf dieses ruggedized NAS kopiert und dann ins Rechenzentrum des Providers gebracht. Noch besser wäre Tape, das leichter zu transportieren und kostengünstiger ist.

Wenn die Daten einmal in der Cloud sind, ist ein tägliches Update ohne große Probleme möglich. Technologien wie Kompression, Deduplikation und die Replikation geänderter Blöcke minimieren den Platzbedarf und die Netzwerkbelastung.

Es gibt noch eine dritte Methode, um Daten in die Cloud zu bewegen. Diese besteht darin, die Produktivdaten direkt in der Cloud laufen zu lassen. Dies ist mittels eines Cache im firmeneigenen Rechenzentrum möglich, der Latenzen vermeidet, oder der Verlagerung des gesamten Workloads in die Cloud. Auch wenn es möglich ist, dass die operativen Vorteile der Verlagerung der gesamten Primär- und Sekundär-Storage die dafür nötigen Ausgaben übertreffen, muss der Kunde sich wohl dabei fühlen, dass all seine Daten in der Cloud sind. Der tägliche Datentransfer entfällt dadurch zwar, aber es muss sichergestellt sein, dass der Provider ausreichende Resilienz bietet.

Schritt 2: Ein Desaster in der Cloud ankündigen

Mindestens einmal in seiner Karriere sieht sich ein Storage-Administrator einem Desaster gegenüber. Wahrscheinlich sogar öfter, denn heute versteht man unter Desaster nicht mehr nur den Totalausfall eines ganzen Rechenzentrums, es genügt bereits der Absturz einer Anwendung.   

Wenn es sich um ein isoliertes Desaster handelt, das nur einen Workload betrifft, ist ein Failover von Compute und Daten an den Cloud-Provider unnötig und unerwünscht. In diesem Fall ist eine Recovery im eigenen Rechenzentrum vorzuziehen.

Einige Cloud-Backup-Produkte nutzen eine On-Premises Appliance, um die Daten der ausgefallenen Anwendung zu hosten und manchmal, um als Compute zu dienen, um eine virtuelle Version der Applikation an den Start zu bringen.

Replikations-basierte DRaaS-Produkte sollten so eingestellt werden, dass sie als Ziel sowohl einen lokalen Speicherort als auch die Cloud nutzen. Auf diese Art kann das Unternehmen Recovery lokal oder in der Cloud angehen.

Wenn das ganze Rechenzentrum ausfällt, wird ein echter Failover in die Cloud unumgänglich. Hier sind im ersten Schritt in der Cloud alle Services zu starten, die kritische Anwendungen wie DNS oder Directory Services benötigen und danach die Server für diese Anwendungen. Schließlich muss die Netzwerkkonfiguration so eingestellt werden, dass die Nutzer sich nahtlose bei den Cloud-Anwendungen einloggen können.

Ein Test, ob alles so funktioniert, ist von entscheidender Wichtigkeit. Besonders die Netzwerkeinstellung sollte überprüft werden. Man sollte auch berücksichtigen, wo sich die Anwender nach einem Ausfall befinden. Wahrscheinlich werden sie nicht in ihren Büros sein, sondern versuchen, sich vom Home Office oder einer Kaffeebar einzuloggen.

Der Prozess läuft bei Unternehmen ähnlich ab, die alle Daten in der Cloud vorhalten, aber Compute im eigenen Rechenzentrum. Die Netzwerkprobleme sind die gleichen, aber weil die Daten sich bereits in der Cloud befinden, müssen nur die Anwendungen neu gestartet werden.

Schritt 3: Rückkehr zum Normalbetrieb

Irgendwann will man die Cloud wieder verlassen und den normalen Betrieb im eigenen Rechenzentrum wiederaufnehmen. Dies ist einer der schwierigsten Aspekte eines Cloud-DR-Planes, denn all die Techniken zur täglichen Datenübertragung funktionieren nicht mehr, weil es keine Grundlage mehr gibt.

In den meisten Fällen ist eine Recovery der Daten aus der Cloud möglich, diese läuft aber langsam ab. Der Provider hostet in der Zwischenzeit Ihre Anwendung. Wenn die Datenübertragung abgeschlossen ist, sollte eine schnelle Datensynchronisierung erfolgen und danach der Betrieb im eigenen Rechenzentrum wieder anlaufen.

Abhängig von der Datenmenge und der verfügbaren Bandbreite kann ein solcher Prozess Tage oder Wochen dauern, während Ihr Unternehmen einen saftigen Aufpreis für die Compute-Nutzung in der Cloud zahlt.      

DRaaS-Anbieter sollten daher eine Option bieten, um die Daten auf einen Schlag ins neue Rechenzentrum zu bringen. Wie schon erwähnt, bieten sich dafür ein ruggedized NAS oder Tape an. Dies kann eine grundlegende Kopie viel schneller wiederherstellen, während die Anwendungen in der Cloud laufen.

Zusammenfassung

Die Cloud kann für DR wertvoll und kosteneffektiv sein. Das liegt daran, dass DR-Storage geringere Kapazität als andere Data-Protection-Produkte erfordert und selten gelesen wird. Der Cloud-Provider kann Zugang zu Compute gewähren, das einen schnellen Neustart wichtiger Anwendungen im Katastrophenfall ermöglicht.

Ein solider Cloud-DR-Plan verringert viele Ausgaben, die im Rahmen einer DR-Strategie anfallen, weil man für Compute nur bei einem tatsächlichen Ausfall oder einem Test bezahlen muss.

Folgen Sie SearchStorage.de auch auf Twitter, Google+, Xing und Facebook!

Nächste Schritte

Mit diesen zehn Tipps können Sie einen Business-Continuity-Plan umsetzen

Methoden für Disaster Recovery für Ihr Unternehmen: Cloud oder Traditionell?

Bringen Software-definierte Netzwerke (SDN) Mehrwerte für Disaster Recovery?

Ausfall von Amazon Web Services: Was heißt das für Disaster Recovery?

Artikel wurde zuletzt im Juni 2017 aktualisiert

Pro+

Premium-Inhalte

Weitere Pro+ Premium-Inhalte und andere Mitglieder-Angebote, finden Sie hier.

Erfahren Sie mehr über Disaster Recovery

Diskussion starten

Schicken Sie mir eine Nachricht bei Kommentaren anderer Mitglieder.

Mit dem Absenden dieser Daten erklären Sie sich bereit, E-Mails von TechTarget und seinen Partnern zu erhalten. Wenn Ihr Wohnsitz außerhalb der Vereinigten Staaten ist, geben Sie uns hiermit Ihre Erlaubnis, Ihre persönlichen Daten zu übertragen und in den Vereinigten Staaten zu verarbeiten. Datenschutz

Bitte erstellen Sie einen Usernamen, um einen Kommentar abzugeben.

- GOOGLE-ANZEIGEN

SearchSecurity.de

SearchNetworking.de

SearchEnterpriseSoftware.de

SearchDataCenter.de

Close