Sichern von Azure-VMs und lokalen virtuellen oder physischen Maschinen mit Cloud-Mitteln in die Azure Cloud (Teil 2)

Du verfügst hoffentlich über ein Backup-Konzept für deine lokalen physischen oder virtuellen Server? Betreibst du außerdem nach und nach mehr Server auch in der Azure-Cloud, bietet es sich eventuell ein, deine Sicherungsstrategie zu überdenken, denn mit „Azure Backup & Site Recovery“ bietet Microsoft einen Service an, der gleichermaßen als Cloud-basierter Backup-Service sowie als kostengünstiges, skalierbares, hochverfügbares und sicheres Speicher-Backend in der Cloud dient. In diesem Beitrag zeigen wir dir das Sichern von Azure-VMs. Dies ist übrigens auch im Kurs Azure AZ 104 (Azure Administrator) sowie die zugehörige Prüfung von Bedeutung. Erfahre mehr in unseren Microsoft Azure Schulungen.

Nachdem wir im ersten Teil die wichtigsten Grundlagen und Fachbegriffe zum Thema Backup im Allgemeinen und im Zusammenhang mit VMs im Besonderen geklärt und uns für den Dienst „Azure Backup & Site Recovery“ in Form eines Sicherungstresors (auch „Recovery Service Vault“ oder „Backup Vault“) entschieden haben, wollen wir den Azure-Plattformdienst in diesem Beitrag bereitstellen, um „damit“ und „darin“ Azure-VMs zu sichern. Suchst du allerdings im Azure-Portal nach „Backup, bekommst du sowohl einige Ergebnisse unter den „Services“, nämlich „Backup Center“, Business Continuity Center“ und „Sicherungstresore“ (in englischer Lokalisierung „Recovery Service Vault“,) als auch einige unter den Marktplatzangeboten, darunter „Azure Backup und Site Recovery“ sowie Azure Backup“.

Zur Einordnung der zugehörigen Azure-Entitäten in Anlehnung an den ersten Teil des Workshops nur so viel: Wir benötigen wahlweise den Dienst „Sicherungstresor” (Recovery Service Vault) oder das Markplatzangebot „Azure Backup und Site Recovery.” Das „Backup Center“ hingegen ist eine übergeordnete Entität zum Verwalten mehrere Sicherungstresore oder Sicherungsrichtlinien und adressiert in erster Linie große Unternehmen, die sämtlich für ihre Sicherungskonzept benötigten Informationen in einer Art zentralem Hub zusammenführen möchten.

Microsoft schreibt dazu: „Backup Center bietet eine zentralisierte einheitliche Verwaltungsumgebung in Azure, mit der Unternehmen Sicherungen in großem Maßstab steuern, überwachen, betreiben und analysieren können. Darüber hinaus werden umfangreiche Überwachungs- und Verwaltungsfunktionen für Azure Site Recovery bereitgestellt.“ Inzwischen hat Microsoft aber auch das Backup Center schon wieder um weitere Funktionen zur umfassenden BCDR-Verwaltung erweitert und im neueren „Business Continuity Center“ vereint.

Wir wollen uns jedoch hier nur mit dem Sichern von Azure-VMs befassen und erstellen zu diesem Zweck einen Sicherungstresor (Recovery Service Vault). Achtung: Während der zu wählen Standort für den Sicherungstresor im Zusammenhang mit Azure Site Recovery durchaus einige Überlegungen erfordert  – so ist es zum Beispiel unklug, wenn auch möglich, für den Sicherungsaufbewahrungsstandort die gleiche Region zu wählen, wie diejenige, vor deren Ausfall du dich eigentlich schützen willst, um die regulatorischen Anforderungen an deine Compliance zu erfüllen  – „muss“ der Standort für den Sicherungstresor beim Backup von Azure-VMs dem Standort der VMs entsprechen. Das nur zur Info.

Wenn Compliance in deinem Unternehmen oder deiner Branche ohnehin über allem steht, hast du deine VMs vermutlich ohnehin in Deutschland und erstellst auch deinen Recovery Service Vault in Deutschland.

Im nächsten Abschnitt „Redundanz“ des Bereitstellungsassistenten kannst du analog zu einem Speicherkonto das gewünschte Redundanzmodell wählen. Im Unterschied zu einem Speicherkonto ist „GRS“ (Georedundant) hier der Standard und du kann das Modell später nur wechseln, solange noch keine Daten im Tresor liegen.   Außerdem kannst du hier (oder später) die „Regionsübergreifende Wiederherstellung“ aktivieren, sofern du das Feature benötigst.

Zur Erinnerung:

• Lokal redundanter Speicher (LRS): LRS repliziert deine Backup-Daten dreimal innerhalb eines einzigen Rechenzentrums in der primären Region1. Dies schützt deine Daten gegen Server-Rack- und Laufwerksausfälle.
• Zonenredundanter Speicher (ZRS): ZRS repliziert deine Backup-Daten in Verfügbarkeitszonen. Dies gewährleistet die Datenresidenz und -resilienz in derselben Region.
• Geo-redundanter Speicher (GRS): GRS repliziert deine Daten in eine sekundäre Region. Dies bietet Schutz gegen regionale Ausfälle.

Der nächste Schritt widmet sich unserem Thema Verschlüsselung aus diesem Artikel (Link). Die Funktionen sind die gleichen, wie bei einem Speicherkonto, d. h. du hast die Wahl zwischen „von Microsoft verwalteten Schlüsseln“ und „kundenseitig verwalteten Schlüsseln“. Weiter geht es zum Schritt „Tresoreigenschaften“. Hier könntest du z. B. ähnlich wie bei einem Speicherkonto die Funktion mithilfe der Eigenschaften des Tresors wieder deaktivieren, sperren und unumkehrbar machen.

Im nächsten Schritt „Netzwerk“ des Bereitstellungsassistenten kannst du die Verbindungsmethode ändern; Default ist hier wie bei einem Speicherkonto „Öffentlicher Zugriff aus allen Netzwerken zulassen“.

Hierzu ein paar Denkanregungen: Eine öffentliche IP-Adresse ist für das Sichern von Azure-VMs nicht erforderlich, weil die gesamte Kommunikation über das sichere Azure-Backbone-Netzwerk erfolgt, egal ob du in der Firewall deines Sicherungstresors einen öffentlichen oder privaten Endpunkt wählst. Die gesamte Kommunikation erfolgt also stets über das sichere Azure-Backbone-Netzwerk, ohne dass ein Zugriff auf deine virtuellen Netzwerke erforderlich ist. Das gilt für VMs „in“ Azure.

Nutzt du aber einen privaten Endpunkt, wird der Datenverkehr zwischen deinen Azure-VMs und dem Recovery Service Vault über das spezifische VNet deiner VMs geleitet. Dies bietet dir eine zusätzliche Sicherheitsebene, weil dann ja sichergestellt ist, dass der Datenverkehr das VNet niemals verlässt. Du könntest deinen Recovery Services Vault sowohl zum Sichern von Azure VMs, also auch lokalen VMs verwenden wollen. In letzteren Fall (den wir im nächsten Teil dieser kleinen Serie besprechen) muss dein Sicherungstresor entweder mit einem öffentlichen Endpunkt konfiguriert sein oder (im Falle des privaten Endpunktes) dein lokales Netzwerk via VPN oder Express Rote Private Peering mit dem virtuellen Netzwerk verbunden sein. Du kannst den Bereitstellungsassistenten nun fertigstellen und nach der erfolgreichen Bereitstellung mit „Zu Ressource wechseln“ direkt zu deinem Sicherungstresor navigieren. Dieser zeigt dir im Abschnitt „Übersicht“ erst einmal sämtliche „Neuigkeiten“, die Microsoft in den letzten Tagen und Wochen implementiert hat. Kaum ein Azure-Service wird nämlich so rege weiterentwickelt wie dieser.

Vorbildlich sind auch die übersichtlichen Quicklinks zur den beiden Haupt-Funktionen „Sicherung“ und „Site Recovery“. Da der Funktionsumfang des Dienstes riesig ist, beschränken wir uns in diesem Teil ausschließlich auf das Sichern von Azure-VMs. Weitere Funktionen diesen Dienstes erklären wir dann später im Zuge weitere Szenarien (Wiederherstellung, Replikation, lokale VMs) im Rahmen von Folge-Artikeln.

Sichern einer Azure VM

Zum Sichern einer Azure-VM klickst du auf der Übersichtseite im Abschnitt „Sicherung“ auf „erste Schritte“ oder du navigierst im Hauptmenü zu „Erste Schritte / Sicherung“ und wählst im Listenauswahlfeld „Wo wird Ihre Workload ausgeführt“  „Azure“ und wählst bei „Was möchten Sie sichern“ den Eintrag „Virtueller Computer“.

Beides entspricht der Default-Einstellung. Ansonsten stehen unter „Wo wird Ihre Workload ausgeführt“ die Optionen „Azure“, „Azure Stack Hub“, „Azure Stack HCI“ und „Lokal“ sowie unter „Was möchten Sie sichern“ im Falle „Azure“ die Optionen „Virtuelle Computer“, „Azure-Dateifreigabe“, „SQL Server auf der Azure-VM“ und „ SAP HANA in Azure VM“ zur Verfügung. Anschließend klickst du auf den Button „Sichern“. Dort wählst du unter „Sicherung konfigurieren“ einen der „Richtlinienuntertypen“ „Erweitert“ oder „Standard“.

Auf den Unterschied gehe ich hier nicht weiter ein; offensichtlich hast du bei „Erweitert“ mehr Konfigurationsmöglichkeiten etwa in Bezug auf die Sicherungshäufigkeit. Bei „Standard“ kannst du z. B. automatisiert nur 1 x Tag sichern (ad hoc natürlich so oft du willst).

Viele weitere Optionen der erweiterten Ebene sind selbsterklärend. Wir werden die Sicherungsrichtlinie selbst auch nicht weiter anpassen (z. B. in puncto Sicherungshäufigkeit, Beibehaltungsdauer von Snapshots zur sofortigen „Schnell“-Wiederherstellung oder „Aufbewahrung des täglichen/wöchentlichen/monatliche und jährliches Sicherungspunktes), da die meisten Optionen selbsterklärend sind und auch den Rahmen des Beitrages sprengen würden. Wie übernehmen einfach die vorgeschlagene Sicherungsrichtlinie für eine vollständige VM-Sicherung mit dem Namen „Default Policy“. Diese erstellt zwar in der Standardkonfiguration die tägliche Sicherung um 6:00 Uhr AM, aber wir können die eigentliche Sicherung für dieses Beispiel abweichend vom standardmäßig erstellten Zeitplan jederzeit ad hoc anstoßen. Du kannst natürlich auch gerne den Zeitplan anpassen.

Wie bei vielen Azure-Diensten, die miteinander integriert sind, könntest du die Sicherung alternativ auch von deiner VM aus starten und dort im Menü „Vorgänge“ auf „Backup und Notfallwiederherstellung / Sicherung“ klicken. Dass sieht dann so aus wie in der untenstehenden Abbildung: Hier kannst du übrigens wählen, ob der erforderliche Recovery Service Vault neu erstellt wird, oder ob du einen Vorhandenen verwendet möchtest.

Ich würde empfehlen, die Sicherung von vorher erstellenten Sicherungstresor aus zu starten, wie oben vorgeschlagen, denn wenn du einfach von der VM aus auf „Sichern“ klickst, ist dir vielleicht nicht bewusst, dass hierbei zusätzliche Kosten entstehen.

Wie im Teil 1 erläutert und im Unterschied zu einem Speicherkonto als Sicherungsziel zahlst du bei einem Sicherungstresor allerdings nur die Speicherkapazität zur Aufbewahrung der jeweiligen Wiederherstellungspunkte (täglich, wöchentlich usw.) sowie für etwaige genutzte Redundanzoptionen oder zusätzliche Features, nicht aber für die Datenübertragung.

Im ersten Fall (Sicherung von Sicherungstresor aus konfigurieren) klickst du auf „Backup aktivieren“; von der VM aus gestartet hingegen heißt der Knopf „Sicherung aktivieren“. Im ersten Fall muss du allerdings zunächst noch die zu sichernden VMs hinzufügen. Dazu klickst du auf den gleichnamigen Button und wählst die gewünschten VMs aus. Tauch hier keine auf, hast du den Tresor nicht in der gleichen Region erstellt, im der sich auch deine VMs befinden:

Klickst du dann auf „Backup aktvieren“ wird der Sicherungsauftrag gemäß Sicherungsrichtlinie erstellt. Je nach Einstellungen in deiner Sicherungsrichtlinie wird das Backup nicht sofort starten, sondern zum konfigurierten Zeitpunkt der Sicherungsrichtlinien.

Klickst du nun auf „Zu Ressource wechseln“, landest du wieder auf der Übersichtsseite deines Sicherungstresors. Klicke jetzt im Menü „Geschützte Elemente“ auf „Sicherungselemente“; solltest du eine „1“ bei „Azure Virtual Maschine“ identifizieren können.

Klickst du auf diesen Eintrag landest du im Dialog Sicherungselemente „Azure Virtual Machine“. Hier sollte deine VM nun mit den Eintrag „Warnung (anfängliche Sicherung steht noch aus)“ in der Spalte „Status der letzten Sicherung“ aufgelistet sein.

Folge nun dem Link „View details“ in der Spalte „Details“. Du landest dann im Blade „<VM-Name> Sicherungselement“ und kannst erkennen, dass es derzeit (noch) keine Wiederherstellungspunkte gibt. Azure Backup klassifiziert diese nach „Anwendungskonsistent“ (Standard bei laufenden Windows-VMs), „Absturzkonsistent (wenn eine VM im Laufe der Sicherung heruntergefahren oder neu gestartet wurde) sowie „Dateisystemkonsistent (Standard bei zum Zeitpunkt der Sicherung ausgeschalteten VMs oder generell bei Linux-VMs). Auch hier erkennst du noch einmal den „Status der letzten Sicherung“:

Nun musst du lediglich auf „Jetzt sichern“ klicken, um abweichend vom konfigurierten Zeitplan jetzt eine Sicherung anzustoßen. Hierbei musst du aber noch bei „Sicherung beibehalten bis“ den gewünschten maximalen Aufbewahrungszeitpunkt angeben. Die maximale Aufbewahrungsdauer für Azure Backup hängt von der spezifischen Konfiguration und den Anforderungen ab, wie etwa der Anzahl der Snapshots. Eine Langzeitaufbewahrung deiner Sicherungsdaten von über 99 Jahre ist konfigurierbar. Erst jetzt nimmt die Azure-Plattform an deiner Azure-VM initiiert über den Azure-VM-Agenten eine ganze Reihe von Erweiterungen vor, welche ich dir im einzelnen im nächsten Abschnitt „Der Sicherungsprozess im Detail“ erläutern möchte.

Vom reinen Workflow her ist das Einrichten einer reinen Azure-VM-Sicherung kein Hexenwerk, wie du soeben gesehen hast. Du solltest nach einiger Zeit bei im Abschnitt „Wiederherstellungspunkte“ bei „Anwendungskonsistente Wiederherstellungspunkte“ eine 1 sehen und darunter die Details der vorhandenen Wiederherstellungspunkte.

Dein neuer Wiederherstellungspunkt hat den Wiederherstellungstyp „Momentaufnahme“ (Snapshot)“.

 Wie du an den Menüpunkten oben erkennst, kannst du von hier aus jederzeit entweder den vollständigen „Virtuellen Computer wiederherstellen“ (Bare Metal Recovery) oder mit „Dateiwiederherstellung“ einzelne Dateien aus den Snapshot in der der noch laufenden VM wiederherstellen. Wie insbesondere Letzteres funktioniert – die komplette VM-Wiederherstellung ist kaum erläuterungsbedürftig – zeige ich dir im nächsten Beitrag. Nun wollen wir uns den Sicherungsprozess etwas genauer ansehen:

Der Sicherungsprozess im Detail

Zunächst startet Azure Backup für jede VM, die du zur Sicherung auswählst wie oben beschrieben einen Sicherungsauftrag, mit dem in der gewählten oder konfigurierten Sicherungsrichtlinie enthaltenen Sicherungszeitplan. Möchtest du anwendungs- oder dateisystemkonsistente Sicherungen (die zu sichernden VMs ist also eingeschaltet) muss auf diesen eine Sicherungserweiterung installiert sein, welche u. a. den Snapshot-Prozess koordiniert. Diese wird in der Regel – also wenn das VM-Image aus dem Azure-Markplatz kommt und daher davon ausgegangen werden kann, dass der Azure-VM-Agent im Image enthalten ist  – im Verlauf der ersten Sicherung (nicht bei der Auftragserstellung) als Extension auf der VM installiert, sofern die VM ausgeführt wird. Bei Bedarf (z. B. Verwendung eines Custom-Images) kannst du die VM-Snapshot-Erweiterung für https://learn.microsoft.com/de-de/azure/virtual-machines/extensions/vmsnapshot-windows Windows-VMs oder https://learn.microsoft.com/de-de/azure/virtual-machines/extensions/vmsnapshot-linux  Linux-VMs aber auch manuell herunterladen und entweder in dein Image integrieren oder in deiner laufenden VM installieren.

Bei laufenden Windows-VMs erstellt Azure Backup in Zusammenarbeit mit dem Volume-Copy-Shadow-Service (VSS) von Windows (siehe Teil1) immer App-konsistente Momentaufnahme der VM und zwar standardmäßig „vollständige“ VSS-Sicherungen. Nur wenn Azure Backup keine App-konsistente Momentaufnahme erstellen kann (weil die VM z. B. aus ist) wird eine dateikonsistente Momentaufnahme des zugrunde liegenden Speichers erstellt (weil keine Schreibvorgänge der Anwendung stattfinden, solange die VM beendet ist).

Bei Linux-VMs erstellt Azure Backup zunächst nur dateikonsistente Sicherungen. Zum Erstellen App-konsistenter Momentaufnahmen unter Linux müsstest du die Pre- und Postskripts manuell anpassen.

Bei Windows-VMs werden dabei eine Reihe von Anpassungen, bzw. Veränderungen automatisch vorgenommen, z. B. Microsoft Visual C++ 2013 Redistributable (x64) Version 12.0.40660 installiert, der Start-Typ des VSS-Diensts (VSS) in automatisch geändert, und der Windows-Dienst IaaSVmProvider hinzugefügt. Konnte Azure Backup die Momentaufnahme erfolgreich erstellen, werden die Daten in den Tresor übertragen. Das geschieht folgendermaßen:

• Zwecks Optimierung der Sicherung werden alle vorhandenen einzelnen VM-Datenträger parallel gesichert, ausgenommen des temporären Datenträgers, der nicht gesichert wird.
• Für jeden zu sicherndem Datenträger liest Azure Backup die Blöcke auf dem Datenträger und identifiziert und überträgt nur die Datenblöcke, die sich seit der letzten Sicherung geändert haben (CBT).
• Die Snapshot-Daten werden nicht notwendigerweise sofort in den Tresor kopiert. Zu Spitzenzeiten vergehen unter Umständen mehrere Stunden. Bei täglichen Sicherungsrichtlinien beträgt die Gesamtdauer der Sicherung eines virtuellen Computers weniger als 24 Stunden. Die untenstehende Abbildung von Microsoft verdeutlicht die Zusammenhänge:

Im dritten Teil dieser kleinen Serie befassen wir uns mit dem Sichern von Azure-Dateifreigaben und spielen verschiedene Szenarien der Wiederherstellung durch. Dabei erörtern wir auch das Thema Datenschutz (Soft-Delete).

Teil vier befasst sich mit der Datei&Ordner-Sicherung und der Wiederherstellung auf lokalen Windows Computern (MARS-Agent) und dem Sichern von lokalen Windows, Linux-VMs unter Hyper-V, VMware, sowie von Exchange- oder SQL-Server-Workloads mithilfe des Azure Backup Servers (MABS).

Teil Fünf befasst sich dann mit dem Feature Azure Site Recovery in verschiedenen Szenarien, also der Replikation von Azure-VMs in einer anderen Region, von lokalen VMs nach Azure von AWS-EC2-VMs zu Azure oder von lokalen VM an einen zweiten lokalen Standort.