Sergey Nivens - stock.adobe.com

Hilfe zur Selbsthilfe nach Ausfall oder Cyberangriff

Erhalten Sie hier eine Anleitung und Fotostrecke dafür, wie ein Rebuild auf Basis der Metadaten von Cloud-Ressourcen Daten, Systeme und Applikationen schnell wieder verfügbar macht.

Je mehr Unternehmen Workloads in die Cloud verlagern, umso wichtiger ist deren Verfügbarkeit auch nach einem Ausfall oder einer Cyberattacke. Hyperscaler bieten zwar durchaus eine hohe Sicherheit für Daten, Ressourcen und Applikationen, allerdings sind auch deren Umgebungen nicht vor Ausfällen oder gegen Cyberangriffe gefeit. IT-Administratoren benötigen daher weitere Rückversicherung: neben dem Angebot der Provider auch eine Möglichkeit, um im Ernstfall selbsttätig und sofort zu handeln und die digitalen Assets mitsamt aller komplexen Konfigurationen schnell und funktionsfähig am gewünschten Ort wiederaufbauen zu können. Eine Lösung für das Replikationsmanagement und zum vollständigen Rebuild der Ressourcen, die ein zusätzlicher Backup von Metadaten zu Konfigurationen und Abhängigkeiten nutzt, erschließt die Möglichkeit zur Selbsthilfe.

Die Cloud verspricht Einfachheit sowie Flexibilität und hält dieses Versprechen auch beim Anlegen und Nutzen von Ressourcen. So löst sie die Kontrolle einer Replikation von der physischen Speicherinfrastruktur. Sie ermöglicht es auch, Ressourcen schnell zu provisionieren und zu deprovisionieren. Hinter dieser Einfachheit verbirgt sich aber eine neue Komplexität sich ständig ändernder Konfigurationen und Abhängigkeiten. Nur wer auf ein Backup der damit einhergehenden Konfigurationen zurückgreifen kann, ist auch in der Lage, in Wirklichkeit komplexe Cloud-Ressourcen schnell wieder aufzubauen.

Ein schnelles, einfaches und weitestgehend automatisiertes Recovery funktionsfähiger Workloads verlangt die kontinuierliche Sicherung der Metadaten im letztmöglichen sicheren Konfigurationsstatus. Das bietet ein Cloud-Dienst nicht unbedingt an. Dieses zusätzliche Backup über Nutzdaten hinaus ist das Drehbuch, um Cloud-Infrastrukturen schnell und funktionsfähig wieder neu aufzubauen. Der Zugriff über eine API erlaubt dabei das Auslesen der inkrementellen Backups in der Hyperscale-Cloud: eine Historie aller Daten und Neukonfigurationen für Daten, Applikationen, Systeme, mitsamt der gegebenen Abhängigkeiten. Auch Updates von Betriebssystemen sind hier verzeichnet.

Rebuild dank Metadaten

Ein Rebuild vollständiger Hyperscaler-Ressourcen auch in der Multi-Cloud ist weit mehr als nur eine Wiederherstellung von Daten oder Einzelsystemen. Eine dafür geeignete Plattform für das Cloud-Datenmanagement mit Rebuild-Funktionen katalogisiert automatisch alle eingesetzten Cloud-Komponenten und weiß so, welche Assets die IT sichern und wiederherstellen muss. Dank Recovery as a Code erfasst sie das vollständige Mapping von Applikationen, Infrastruktur und Netzwerkkonfigurationen. Durch eine Drift-Analyse kann sie veränderte Konfigurationen nachvollziehen.

Die dafür auszulesenden Backups mit den notwendigen Metadaten liegen über verschiedene Cloud-Dienste hinweg in nicht manipulierbaren Kopien in Air-Gap-Lokationen und getrennt von den produktiven Systemen, Sie sind daher vor Angriffen zusätzlich geschützt. Ein solches resilientes Metadaten-Backup sichert Daten von Cloud-basierten Applikationssystemen automatisiert kontinuierlich, verteilt, verschiebbar und dynamisch – als Basis für den schnellen Wiederaufbau im Ernstfall.

Dank einer kontinuierlichen Sicherung können Administratoren im Idealfall auf den Zeitpunkt unmittelbar vor einem erfolgten Ausfall oder Angriff über die API einer Hyperscaler-Cloud zurückgreifen und so die gesamte Struktur in einem hohen Grad automatisiert wieder aufbauen. Letztlich spult der Nutzer auf der Zeitachse der Konfiguration auf den letzten Zeitpunkt eines funktionsfähigen oder Malware-freien Metadaten-Snapshots. Dies kann allein auf Betreiben des entsprechenden IT-Verantwortlichen und ohne Zutun eines Hyperscale-Providers erfolgen.

Zusatz(ver)sicherung einbauen

Mit geeigneten Tools kann ein IT-Administrator beim Management der Backup-Replika im Vorfeld Maßnahmen ergreifen, die ihm im Ernstfall das selbsttätige Recovery effizient und sicher ermöglichen. Ebenso kann er das Recovery zu dem Zeitpunkt starten, wenn er sie starten möchte.

Christian Kubik, Commvault

„Hyperscaler bieten zwar durchaus eine hohe Sicherheit für Daten, Ressourcen und Apps, doch auch deren Umgebungen sind nicht vor Störungen gefeit. IT-Admins benötigen daher weitere Rückversicherung: neben dem Provider auch eine Möglich-keit, um im Ernstfall selbsttätig und sofort die digitalen Assets mitsamt den Konfigurationen funktionsfähig wiederaufbauen zu können.“

Christian Kubik, Commvault

Von vornherein kann er etwa eine sekundäre Disaster-Recovery-Region für ein Backup frei wählen – abweichend von der durch den Cloud Service Provider per Default fix festgeschriebenen Disaster-Recovery-Region. Damit kann er eigene Präferenzen oder Notwendigkeiten durchsetzen oder möglicherweise schneller Strukturen wieder aufbauen. Das bringt unter Umständen Zeit, wenn die individuell ausgewählte DR-Region nicht von allen anderen Opfern eines Ausfalls in einer Region betroffen und die Default-DR-Region deshalb überlastet ist. Zudem kann ein IT-Administrator auf von ihm bemerkte Ausfälle oder einen Angriff sofort reagieren. Das kann eine Rolle spielen, wenn ein Provider bei kleineren Performance- oder Verfügbarkeitsproblemen noch nicht handeln muss oder sobald ein Admin einen externen Angriff erkennt. Ein IT-Administrator kann dank einer Cloud-Plattform selbst entscheiden, ob er aktiv werden will und Ressourcen aus einer vorab gewählten alternativen DR-Region wieder einspielt.

Ein schneller Rebuild durch ein flexibles Replikationsmanagement bietet zudem noch zusätzliche Sicherheiten durch die Möglichkeit externer Notfall-Accounts.  Selbst wenn Hacker das gesamte Cloud-Konto eines angegriffenen Unternehmens kompromittiert haben, erschließen diese Zugänge externen legitimierten Nutzern – etwa bei einem Managed Service Provider – die Möglichkeit, Daten und Applikationen wiederherzustellen. Das ist nicht nur Account-übergreifend, sondern auch über verschiedene Regionen hinweg möglich. Einen weiteren Sicherheitslevel bieten verschiedene Verschlüsselungen und rotierende Entschlüsselungs-Keys für die Backups.

Die folgende Bilderstrecke beschreibt die Einrichtung einer sekundären Backup-Region in einer Azure-Subskription mit Commvault Cloud Rewind. Die Workloads befinden sich in der Region UK South. Die Sicherung der Backups will der Verantwortliche dann in die Backup-Region UK West replizieren.

Abbildung 1: Übersicht der Azure-Subskription mit allen Workloads, die Commvault Cloud Rewind sichert. (Quelle: Commvault)
Abbildung 1: Übersicht der Azure-Subskription mit allen Workloads, die Commvault Cloud Rewind sichert. (Quelle: Commvault)
Abbildung 2: Das Backup erfolgt mit Cloud Rewind, das im Commvault Cloud SaaS Portal Service Catalog als Anwendung verfügbar ist. (Quelle: Commvault)
Abbildung 2: Das Backup erfolgt mit Cloud Rewind, das im Commvault Cloud SaaS Portal Service Catalog als Anwendung verfügbar ist. (Quelle: Commvault)
Abbildung 3: Das Cloud Rewind Dashboard zeigt auf einen Blick die Gesamtzahl der zu sichernden Ressourcen und ihren Ort. (Quelle: Commvault)
Abbildung 3: Das Cloud Rewind Dashboard zeigt auf einen Blick die Gesamtzahl der zu sichernden Ressourcen und ihren Ort. (Quelle: Commvault)
Abbildung 4: Das Sichern von Cloud-Ressourcen erfolgt über Cloud Assemblies. Diese definieren, was wie zu sichern ist. (Quelle: Commvault)
Abbildung 4: Das Sichern von Cloud-Ressourcen erfolgt über Cloud Assemblies. Diese definieren, was wie zu sichern ist. (Quelle: Commvault)
Abbildung 5: Jede Cloud Assembly nutzt eine Cloud Connection, um Ressourcen zu identifi-zieren und zu sichern. Hier Azure. Die primäre Backup-Region ist UK South, und der IT-Administrator repliziert die Backups nun zusätzlich nach UK West. Für virtuelle Disks nutzt das Tool Snapshots als Sicherungsstrategie, alle anderen Ressourcen (Konfigurationen, Meta-daten und andere) sichert Cloud Rewind. (Quelle: Commvault)
Abbildung 5: Jede Cloud Assembly nutzt eine Cloud Connection, um Ressourcen zu identifi-zieren und zu sichern. Hier Azure. Die primäre Backup-Region ist UK South, und der IT-Administrator repliziert die Backups nun zusätzlich nach UK West. Für virtuelle Disks nutzt das Tool Snapshots als Sicherungsstrategie, alle anderen Ressourcen (Konfigurationen, Meta-daten und andere) sichert Cloud Rewind. (Quelle: Commvault)
Abbildung 6: Die jeweilige Cloud Connection definiert die Konnektivität zum jeweiligen Cloud-Anbieter und wird von einer oder mehreren Cloud Assemblies zum Sichern der Daten genutzt. (Quelle: Commvault)
Abbildung 6: Die jeweilige Cloud Connection definiert die Konnektivität zum jeweiligen Cloud-Anbieter und wird von einer oder mehreren Cloud Assemblies zum Sichern der Daten genutzt. (Quelle: Commvault)
Abbildung 7: In der Cloud Assembly definiert der Admin, welche Daten zu sichern sind. Dies kann auf Basis von Ressource Groups in Azure geschehen oder durch Tags. (Quelle: Commvault)
Abbildung 7: In der Cloud Assembly definiert der Admin, welche Daten zu sichern sind. Dies kann auf Basis von Ressource Groups in Azure geschehen oder durch Tags. (Quelle: Commvault)
Abbildung 8: In AWS definiert der Admin Ressourcen auf Basis des VPC, durch manuelle Auswahl oder definiert über Tags. (Quelle: Commvault)
Abbildung 8: In AWS definiert der Admin Ressourcen auf Basis des VPC, durch manuelle Auswahl oder definiert über Tags. (Quelle: Commvault)
Abbildung 9: Nach Einrichten der Inhalte zeigt die Cloud Assembly übersichtlich an, welche Daten zu sichern sind. Im ursprünglichen Azure-Szenario handelt es sich um zwei virtuelle Maschinen und einige zugehörige Objekte. (Quelle: Commvault)
Abbildung 9: Nach Einrichten der Inhalte zeigt die Cloud Assembly übersichtlich an, welche Daten zu sichern sind. Im ursprünglichen Azure-Szenario handelt es sich um zwei virtuelle Maschinen und einige zugehörige Objekte. (Quelle: Commvault)
Abbildung 10: Jeder Cloud Assembly weist der Nutzer eine Protection-Policy zu. Diese Richtlinie bestimmt, wie häufig das Backup erfolgt und für wie lange die Daten vorgehalten sind. (Quelle: Commvault)
Abbildung 10: Jeder Cloud Assembly weist der Nutzer eine Protection-Policy zu. Diese Richtlinie bestimmt, wie häufig das Backup erfolgt und für wie lange die Daten vorgehalten sind. (Quelle: Commvault)
Abbildung 11: Die in diesem Fall gewählte Protection Policy hebt drei Backups (Retention Count) auf und läuft alle drei Stunden (Protection Frequency). Backup-Daten sind nach erfolgter Sicherung nach UK West zu replizieren. (Quelle: Commvault)
Abbildung 11: Die in diesem Fall gewählte Protection Policy hebt drei Backups (Retention Count) auf und läuft alle drei Stunden (Protection Frequency). Backup-Daten sind nach erfolgter Sicherung nach UK West zu replizieren. (Quelle: Commvault)
Abbildung 12: Die Timeline-Registerkarte der Cloud Assembly zeigt die vorherigen Backups und deren Status an. Die letzten drei Backups vom heutigen Tag sind noch aufbewahrt (grüner Haken). Vorherige Backups sind bereits aus der Retention gelaufen. Gemäß Policy liegt die Höchstzahl aufbewahrter Backups bei drei. (Quelle: Commvault)
Abbildung 12: Die Timeline-Registerkarte der Cloud Assembly zeigt die vorherigen Backups und deren Status an. Die letzten drei Backups vom heutigen Tag sind noch aufbewahrt (grüner Haken). Vorherige Backups sind bereits aus der Retention gelaufen. Gemäß Policy liegt die Höchstzahl aufbewahrter Backups bei drei. (Quelle: Commvault)
Abbildung 13: Ein Report zeigt sowohl die Details der erfolgreichen Sicherung in der vorgesehenen Region UK South als auch in der zusätzlichen DR-Region UK West. (Quelle: Commvault)
Abbildung 13: Ein Report zeigt sowohl die Details der erfolgreichen Sicherung in der vorgesehenen Region UK South als auch in der zusätzlichen DR-Region UK West. (Quelle: Commvault)
Abbildung 14: Für eine Recovery kann ein IT-Administrator wahlweise die gesamte Cloud Assembly oder nur ausgewählte Ressourcen wiederherstellen. (Quelle: Commvault)
Abbildung 14: Für eine Recovery kann ein IT-Administrator wahlweise die gesamte Cloud Assembly oder nur ausgewählte Ressourcen wiederherstellen. (Quelle: Commvault)
Abbildung 15: Nach einer Test-Recovery löscht ein Scheduled Reset die im Test wiederherge-stellten Ressourcen nach einer festgelegten Zeit automatisch. (Quelle: Commvault)
Abbildung 15: Nach einer Test-Recovery löscht ein Scheduled Reset die im Test wiederherge-stellten Ressourcen nach einer festgelegten Zeit automatisch. (Quelle: Commvault)
Abbildung 16: Recovery-Status aller wiederhergestellten Ressourcen. (Quelle: Commvault)
Abbildung 16: Recovery-Status aller wiederhergestellten Ressourcen. (Quelle: Commvault)
Abbildung 17: Ein Log-Report dokumentiert die Details eines Recovery und würde Fehler aufzeichnen. (Quelle: Commvault)
Abbildung 17: Ein Log-Report dokumentiert die Details eines Recovery und würde Fehler aufzeichnen. (Quelle: Commvault)
Abbildung 18: Finaler Report über das Recovery der Ressourcen. (Quelle: Commvault)
Abbildung 18: Finaler Report über das Recovery der Ressourcen. (Quelle: Commvault)
Abbildung 19: So sieht die Sicherung nach der DR-Region UK West im Azure Portal aus. (Quelle: Commvault)
Abbildung 19: So sieht die Sicherung nach der DR-Region UK West im Azure Portal aus. (Quelle: Commvault)

Über den Autor:
Christian Kubik ist Manager Field Advisory Services Team EMEA bei Commvault.

Die Autoren sind für den Inhalt und die Richtigkeit ihrer Beiträge selbst verantwortlich. Die dargelegten Meinungen geben die Ansichten der Autoren wieder.

Erfahren Sie mehr über Backup-Lösungen und Tools