Der Trend bei Backup und Recovery geht immer mehr in die Cloud. Dabei gibt es mehrere Ansätze: Neben herkömmlicher Datensicherung inklusive der Möglichkeit, Informationen wiederherzustellen, können Unternehmen auch komplette Desaster-Recovery-Infrastrukturen aufbauen. Wir zeigen, welche Möglichkeiten es dazu gibt und welche Vorteile sich dabei ergeben.
Fallen Rechenzentren aus, zum Beispiel wegen Hochwasser, Stromausfall oder aufgrund eines Ransomware-Angriffs, sollten Unternehmen vorbereitet sein. Denn Datenverluste resultieren in Einbrüchen bei der Produktion und damit in finanziellen Verlusten – Firmen sind nicht mehr handelsfähig, wenn die IT in die Knie geht. Ist die lokale Infrastruktur down, bringt auch eine Datensicherung zunächst einmal nichts. Denn ohne eine laufende IT-Umgebung lassen sich selbst gesicherte Daten nicht nutzen. Zudem dauert es eine gewisse Zeitspanne, bis eine komplette Datensicherung wieder eingespielt ist.
Das einfache Auslagern von Diensten in die Cloud stellt deshalb noch kein Recovery-Konzept dar. Zudem müssen Organisationen bei der Inanspruchnahme von Clouddiensten das Shared-Responsibility-Modell beachten. Dies besagt, dass der Cloudanbieter zwar die Infrastruktur zur Verfügung stellt und betreibt. Er sichert aber keinerlei Daten – dafür ist der Kunde verantwortlich.
Oberstes Ziel: Geschäftsbetrieb aufrechterhalten
Unternehmen sollten also genau planen, was der Ausfall der IT-Infrastruktur für einzelne Abteilungen und Workloads bedeutet. Die genauen Auswirkungen muss jede Organisation für sich selbst erkunden. Ein Punkt ist jedoch für alle Firmen gleich: Die Verantwortlichen sind oft überrascht, welche umfassenden, negativen Auswirkungen zu verzeichnen sind, wenn die IT im Unternehmen ausfällt.
Fallen Rechenzentren aus, zum Beispiel wegen Hochwasser, Stromausfall oder aufgrund eines Ransomware-Angriffs, sollten Unternehmen vorbereitet sein. Denn Datenverluste resultieren in Einbrüchen bei der Produktion und damit in finanziellen Verlusten – Firmen sind nicht mehr handelsfähig, wenn die IT in die Knie geht. Ist die lokale Infrastruktur down, bringt auch eine Datensicherung zunächst einmal nichts. Denn ohne eine laufende IT-Umgebung lassen sich selbst gesicherte Daten nicht nutzen. Zudem dauert es eine gewisse Zeitspanne, bis eine komplette Datensicherung wieder eingespielt ist.
Das einfache Auslagern von Diensten in die Cloud stellt deshalb noch kein Recovery-Konzept dar. Zudem müssen Organisationen bei der Inanspruchnahme von Clouddiensten das Shared-Responsibility-Modell beachten. Dies besagt, dass der Cloudanbieter zwar die Infrastruktur zur Verfügung stellt und betreibt. Er sichert aber keinerlei Daten – dafür ist der Kunde verantwortlich.
Oberstes Ziel: Geschäftsbetrieb aufrechterhalten
Unternehmen sollten also genau planen, was der Ausfall der IT-Infrastruktur für einzelne Abteilungen und Workloads bedeutet. Die genauen Auswirkungen muss jede Organisation für sich selbst erkunden. Ein Punkt ist jedoch für alle Firmen gleich: Die Verantwortlichen sind oft überrascht, welche umfassenden, negativen Auswirkungen zu verzeichnen sind, wenn die IT im Unternehmen ausfällt.
Sind also die Auswirkungen des Ausfalls eines Rechenzentrums dokumentiert, besteht der nächste Schritt darin, zu planen, wie sich solche Downtimes kompensieren oder sogar verhindern lassen. Dabei stellen sich im Grunde genommen drei Fragen:
1. Wie schnell lassen sich die notwendigen Geschäftsprozesse im Unternehmen mit der geplanten Vorgehensweise bei einem Ausfall der IT-Infrastruktur wiederherstellen, sodass die Mitarbeiter wieder arbeiten können?
2. Wie erfolgt die Wiederherstellung der Daten aus dem Backup, wenn die Notfall-IT-Infrastruktur aktiviert ist, und wie lange dauert das Recovery?
3. Wie viele Daten gehen dabei verloren und ist dieser Datenverlust akzeptabel? Bei einer täglichen Datensicherung etwa gehen alle Daten des Arbeitstags verloren, wenn keine weitere Sicherung oder Replikation erfolgt.
Gespiegeltes RZ – nichtganz einfach und teuer
Eine Möglichkeit für Recovery-Pläne ist der Aufbau einer gespiegelten Infrastruktur in Form von verschiedenen Rechenzentren. Das bedeutet hohe Kosten in Form von Infrastruktur und Personal, um ein solches zweites RZ zu betreiben. Es muss zudem geografisch weit genug entfernt sein, damit Ausfälle des einen nicht auch das andere Rechenzentrum betreffen.
Der Aufbau eines gespiegelten Rechenzentrums hat nicht zuletzt Anforderungen an die Datenleitung zwischen den Standorten. Diese muss im Bedarfsfall in der Lage sein, die Datenmenge vom Ausfallsrechenzentrum auch transportieren zu können. Dazu kommt das Personal, das jederzeit zu den Betriebszeiten des Unternehmens bereit sein muss, das Rechenzentrum in Betrieb zu nehmen. Zudem gilt es, die Server und die Infrastruktur im zweiten Rechenzentrum ständig aktuell und am Laufen zu halten. Entscheidend ist zudem die Replikation der Daten zwischen den Rechenzentren, damit sich bei einem Ausfall den Betrieb wieder aufnehmen lässt.
Zusätzlich stellt sich die Frage der Sicherheit: Wenn sich im ersten Rechenzentrum Malware ausgebreitet hat, besteht die Gefahr, dass die Replikation die Malware an den zweiten Standort kopiert. Hier müssen die Sicherheitsexperten dafür sorgen, dass im zweiten Rechenzentrum die Berechtigungen so gesetzt sind, dass Schadsoftware keine Chance hat.
Hybride Sicherungen zwischen Cloud und lokaler Umgebung
Da der Aufbau eines gespiegelten Rechenzentrums für die meisten Unternehmen wirtschaftlich kaum sinnvoll ist, kommen hybride Netzwerke zum Einsatz. Hier setzen Organisationen teilweise auf Cloudinfrastrukturen. Dabei kommen vor allem Backups in der Cloud zum Einsatz und Clouddienste, die produktiv im lokalen Netzwerk Verwendung finden.
Hier stellen sich die gleichen Fragen: Wie lange dauert es, die Daten aus der Cloud wieder in die lokale Infrastruktur zu überspielen, die den Ausfall des Rechenzentrums kompensiert? Und wo soll diese IT-Infrastruktur positioniert sein? Denn ohne funktionsfähige Umgebung bringt auch eine Datensicherung in der Cloud nicht viel. Das heißt, es muss ein Plan bereitstehen, wie eine ausgefallene IT-Infrastruktur schnellstmöglich wieder zum Einsatz kommt.
Auch bei der Nutzung von Clouddiensten kommen IT-Verantwortliche nicht darum herum, sich zu überlegen, welche Abhängigkeiten mit lokalen Rechenzentren bestehen. Dazu gesellen sich wie schon angesprochen Anforderungen an Datenschutz, Sicherheit und Berechtigungsstruktur.
Bild 1: Amazon bietet mit AWS Elastic Disaster Recovery einen Dienst für das Disaster-Recovery aus der Cloud.
Backup und Recovery komplett in die Cloud auslagern
Lagern Unternehmen das Backup und die Recovery-IT-Infrastruktur komplett in die Cloud aus, besteht zunächst der Vorteil, dass sich die Fragen der Wiederherstellung schnell beantworten lassen. Da Daten und IT-Infrastruktur in der Cloud positioniert sind, lassen sich die Geschäftsprozesse sehr schnell wieder zum Laufen bringen. Bei einem solchen Szenario liegt nicht nur ein Backup der Daten vor, sondern auch eine Sicherung der kompletten IT-Infrastruktur.
Bei einem Ausfall des lokalen RZs verfügt das gespiegelte Rechenzentrum in der Cloud über alle Daten. Admins müssen dann nur noch die virtuellen Computer und Dienste aktiv schalten. Danach können die Anwender weiterarbeiten, während sich IT-Experten in Ruhe um die Wiederherstellung des lokalen Rechenzentrums kümmern.
Virtuelle Infrastrukturen in der Cloud ermöglichen die umfassende Spiegelung von Berechtigungen, Compliance und Sicherheitseinstellungen des lokalen Rechenzentrums in die Cloud. Betrieb, Aufbau und Verwaltung sind Sache des Cloudanbieters. Hier bestehen bezüglich der Geschwindigkeit der vollständigen Wiederherstellung eines Rechenzentrums zahlreiche Vorteile.
Nicht zu vergessen ist dabei jedoch die Frage, was die Aufrechterhaltung einer Recovery-IT-Infrastruktur in der Cloud kostet. Auch die Datenleitung vom Unternehmen in die Cloud muss wie schon erwähnt für die große Datenmengen geeignet sein, die bei der Aktivierung des Recovery-Plans anfallen. Dazu kommen Vorkehrungen, um auch das gespiegelte Rechenzentrum in der Cloud vor Ransomware zu schützen.
Große Anbieter wie Amazon, Microsoft und Google haben dafür spezielle Dienste im Einsatz und sind für den Schutz vor Angreifern vorbereitet. AWS Elastic Disaster Recovery (DSR) etwa ist ein solcher Dienst, der Anwendungen aus dem lokalen Rechenzentrum in wenigen Minuten in der Cloud aktiv schalten kann. Die Vorhaltung der Infrastruktur kostet nur sehr wenig, da die Kosten erst bei Inbetriebnahme anfallen. Die Daten aus dem lokalen Rechenzentrum synchronisieren sich laufend in die Cloud. Dabei fallen Gebühren für die Speicherung der Daten an.
Die Vorteile solcher Angebote liegen auf der Hand. Zunächst lassen sich kostengünstig Recovery-Umgebungen in der Cloud für Daten und IT-Infrastruktur schaffen. Diese Infrastruktur kann Downtimes von On-Premises-Rechenzentren entgegenwirken, aber auch als Ausfallschutz für andere Cloudinfrastrukturen dienen.
Bild 1: Amazon bietet mit AWS Elastic Disaster Recovery einen Dienst für das Disaster-Recovery aus der Cloud.
Auch virtualisierte Umgebungen absichern
Haben Unternehmen ihre Daten in die Cloud gesichert, inklusive einer Replikation und einer virtuellen IT-Infrastruktur, die das lokale Rechenzentrum in der Cloud abbildet, besteht die Möglichkeit, bei Ausfall von lokalen Datencentern die Workloads in kurzer Zeit in der Cloud bereitzustellen. Dazu starten Sie die VMs, die Sie im Vorfeld in der Cloud konfiguriert haben. Mit einem solchen Szenario können Unternehmen auch komplexe Datenbankanwendungen schützen und Workloads wie SAP und andere Unternehmenssoftware.
In Desaster-Szenarien lassen sich neben physischen Servern auch komplette Virtualisierungsumgebungen einbinden, zum Beispiel mit VMware vSphere oder Microsoft Hyper-V. Die Integration von bekannten Sicherungslösungen wie Veeam Backup ist problemlos umsetzbar.
Cloudinfrastrukturen bei anderen Anbietern oder aus anderen Regionen lassen sich auf diesem Weg ebenfalls vor Ausfällen schützen und einfach wiederherstellen. Gehen lokale Strukturen oder Dienste bei anderen Dienstleistern in die Knie, schalten sich VMs des Desaster-Recovery in der Cloud aktiv und übernehmen den Betrieb der Workloads.
Ausfälle gehören in diesem Fall der Vergangenheit an und komplette Clusterumgebungen lassen sich auf einen Schlag über die Cloud hochverfügbar bereitstellen. Solange die Failover-Umgebung zur Sicherheit nur bereitsteht, entstehen dabei kaum Kosten.
Beispiel AWS
Am Beispiel von AWS DRS erstellen Sie im Vorfeld ein virtuelles Rechenzentrum, das die Workloads des Unternehmens aus verschiedenen Quellen bereitstellen kann, wenn ein Desaster-Recovery notwendig ist. Dazu richten Sie auf den Quell-VMs auch Replikationen der Daten mit einem speziellen Subnetz in AWS ein. Dieses spezielle Staging-Area-Subnetz stellt kostengünstig Ressourcen bereit. Die Preise für den Dienst listet Amazon hier [1] auf.
Unabhängig von der Infrastruktur und wo die Quellserver im Einsatz sind, ist es auch möglich, unterschiedliche Betriebssysteme mit Diensten wie AWS DRS zu schützen. Windows- und Linux-Systeme lassen sich problemlos anbinden, genauso wie zahlreiche Workloads. Datenbanken wie Oracle MySQL oder Microsoft SQL Server sind ebenfalls integrierbar, und auch ganze Virtualisierungscluster auf Basis von VMware vSphere oder Microsoft Hyper-V sind sicherbar. Nicht zuletzt kann DRS die EC2-Instanzen anderer AWS-Regionen schützen.
AWS Elastic Disaster Recovery hilft zusätzlich gegen Ransomware. Im Idealfall können Sie bei der Replikation vom lokalen Rechenzentrum in die Cloud bereits die Malware entfernen. Zusätzlich bietet DRS auch Point-in-Time-Recovery. Damit lassen sich Daten exakt zu einem Zeitpunkt wiederherstellen, an dem sie noch frei von Ransomware waren. Im Idealfall werden so innerhalb weniger Minuten eigentlich erfolgreiche Ransomware-Attacken zunichte gemacht. Ist der Sicherheitsvorfall im lokalen Rechenzentrum dann behoben, führen Admins einen Failback in der Konsole von DRS durch.
Die Funktionalität des Desaster Recovery sollten Sie über Tests der Umgebung verifizieren. Diese können Desaster- und Failback-Szenarien umfassen. Das stellt sicher, dass das Setup im Notfall auch funktioniert. Dazu steht die AWS Desaster Recovery Console zur Verfügung, mit der Admins jederzeit den Zustand der Umgebung und die korrekte Datenreplikation überwachen können.
AWS bietet zusammen mit VMware einen Clouddienst an, der sich über DRS anbinden lässt. ZBackup ist es so möglich, Backupdaten in die Cloud zu übertragen und bei einer Wiederherstellung zu nutzen. Veeam Backup & Replication verwendet dann VMware Cloud in AWS als Repository für die Sicherung von Daten. Auf diesem Weg lässt sich die implementierte Disaster-Recovery-Umgebung auch für die Migration von Workloads und kompletter Infrastrukturen in die Cloud nutzen.
Beispiel IONOS
Neben der einfachen Sicherung von Daten aus dem lokalen Rechenzentrum in die Cloud mittels "IONOS Cloud Backup" hat der Hoster auch komplette Disaster-Recovery-Angebote für ganze Rechenzentren oder einzelne Dienste im Portfolio. Haben Unternehmen ihre Daten in die Cloud gesichert, inklusive einer Replikation und einer virtuellen IT-Infrastruktur, die das lokale RZ in der Cloud abbildet, besteht bei einem Ausfall von On-Premises-Datencentern die Möglichkeit, die Workloads in kurzer Zeit in der Cloud bereitzustellenie Die Disaster-Recovery-Instanz greift dann als Datenbestand auf die Sicherungen zu – das System funktioniert ähnlich wie Amazon DRS.
Im Rahmen der Vorkehrungen gegen ein Desaster erfolgt die Vorbereitung der abzusichernden Server in der IONOS-Cloud. Alle Server, die das Unternehmen vor einem Ausfall schützen sollen, bereiten Sie in der IONOS-Cloud innerhalb eines virtuellen Rechenzentrums auf der IONOS Compute Engine vor. Um die Kosten der Plattform zu reduzieren, können Sie die Ressourcen der Backupserver im Vergleich zu den originalen Servern absenken. Auch hier sind die Daten der Quell-VMs ständig mit denen der Ziel-VMs synchron.
DR-Vorgang mit Carbonite Availability steuern
Zum Steuern von Disaster-Recovery-Vorgängen kann "Carbonite Availability" zum Einsatz kommen. Die Software repliziert kontinuierlich sämtliche Daten und Anwendungen aller abgesicherten Systeme in die Cloud. Ist auf einem Quellserver zum Beispiel ein Apache-Webserver installiert, kann das Werkzeug die komplette Anwendung inklusive der Daten vom Quell- auf den Zielserver synchronisieren und für das Disaster Recovery aktivieren. Dabei kommen spezielle Agenten zum Einsatz, die die Daten von den Quell- zu den Zielservern replizieren. Ausfallzeiten und langwierige Failover-Vorgänge lassen sich dadurch minimieren.
Die Zuverlässigkeit des Systems geht sogar so weit, dass Nutzer mit diesem Hilfsmittel auch Migrationen von lokalen Servern in die Cloud durchführen können. Im Rahmen eines solchen Umzugs synchronisiert Carbonite den kompletten Server mit allen Workloads in die Cloud und Anwender arbeiten ohne Unterbrechung weiter. Die migrierten Server lassen sich dann etwa mit IONOS Backup sichern.
Bei einem Ausfall des Ursprungssystems lässt sich über die zentrale Managementplattform von Carbonite Availability granular das Failover betroffener Dienste verwalten. Hierbei übernimmt das System sämtliche Konfigurations- und Dateninhalte auf das Zielsystem und die Anwender arbeiten mit dem aktuellen Datensatz weiter. Diese Vorgänge dauern nur wenige Minuten.
Sobald das ursprüngliche System wiederhergestellt ist, führt Carbonite Availability ein Failback durch und die Kollegen arbeiten wieder mit ihrem gewohnten System. Schließlich geht das Disaster-Recovery-System wieder in den (günstigen) Wartemodus. Zusätzlich bietet das Tool neben einem umfangreichen Reporting die Möglichkeit, definierte Szenarien ohne Einfluss auf den Betrieb regelmäßig zu testen. Parallel dazu erfolgt das regelmäßige Erstellen von Sicherungspunkten – wie schon angesprochen eine wichtige Funktionalität im Fall eines erfolgreichen Ransomware-Angriffs.
Fazit
Ob IONOS, AWS oder ein anderer Anbieter: Es gibt viele Möglichkeiten, um Sicherungen und Wiederherstellungen in und aus der Cloud durchzuführen. Neben der Sicherung von Informationen in lokalen Rechenzentren oder bei anderen Clouddienstleistern lassen sich selbst komplette Rechenzentren schützen und wiederherstellen. Recovery-Vorgänge laufen dann im Idealfall über eine zentrale Konsole ab und selbst umfassende Disaster-Recovery-Vorgänge sind in wenigen Minuten abgeschlossen – wenn die Vorbereitung stimmt.