Die Prämisse für diesen Workshop ist folgende: Als Sicherungsziel soll Azure beziehungsweise eines der über 60 Azure-Rechenzentren weltweit dienen. Die dazu betrachteten Tools müssen zudem im weitesten Sinne aus dem Azure-Sortiment stammen. Bei der Sicherungsquelle hingegen wollen wir jedes denkbare Szenario, also lokale, in Azure oder einer anderen Cloud liegende physische und virtuelle Server berücksichtigen.

Dabei geht es uns nicht um das genaue Vorgehen in der Anwendung, sondern vor allem um technische Details und Besonderheiten der jeweiligen Herangehensweise, deren Vor-/Nachteile sowie die daraus resultierenden Kosten. Dazu wollen wir die folgenden Wege und Werkzeuge hinsichtlich Funktionalität (volles VM-Backup mit anwendungskonsistenten Widerherstellungspunkten, Dateien/Ordner, Systemzustand, Bare-Metal-Recovery), Flexibilität, Kosten und Verwaltbarkeit vergleichen:

1. Drittanbieter-Sicherungssoftware (TSM/ Spectrum Protec, Commvault, Acronis, Veeam) mit Sicherungsziel Azure Storage Account

2. Azure-VM mit Sicherungsziel "Azure Backup/Recovery Service Vault” (RSV)

3. Microsoft Azure Backup Server (MABS) oder System Center Data Protection Manager (DPM) mit Sicherungsziel "Azure Backup/Recovery Service Vault” (RSV)

4. Datei- und Ordner-Backup mit "Microsoft Azure Recovery Service Agent” (MARS) mit Sicherungsziel "Azure Backup/Recovery Service Vault” (RSV).

Schließlich werfen wir noch einen Blick auf das Azure Backup Center, eine GUI im Azure-Portal, die einen Großteil der oben skizzierten Strategien unter eine organisatorische Haube bringt – einschließlich der Möglichkeit, auch Backups von Azure-Datenträgern, Azure Blobs, Azure Files, SQL auf Azure VM, HANA auf Azure VM und Azure Database für PostgeSQL Server anfertigen zu können.

Ausschließen wollen wir ausdrücklich die bei vielen PaaS-Diensten (Platform-as-a-Service) in Azure ohnehin eingebaute Backup-Möglichkeit, etwa bei Azure App Service, Azure SQL Database oder CosmosDB. Ebenfalls nicht behandeln werden wir das Replizieren von VMs und physischen Servern in Azure oder einen beliebigen sekundären Standort, auch wenn dieser Punkt einen Großteil der Funktionalität des Microsoft-Diensts Azure Backup ausmacht. Ebensowenig betrachten wir die Möglichkeit, dass Sie jederzeit Snapshots von einzelnen Datenträgern sowie generalisierte oder spezialisierte Images ihrer virtuellen Maschinen anfertigen können.

Leider lassen sich die verwendeten Begrifflichkeiten, wie auch an anderen Stellen in Azure, nicht ganz einfach einordnen. Die Sicherungsentität, auf der der Service "Azure Backup" und letztlich auch das Backup-Center aufsetzen, ist der "Recovery Services Tresor" (Recovery Services Vault). Dieser stellt seinerseits auch die GUI für die meisten oben skizzierten Szenarien bereit, auch ohne das Azure Backup Center. Verbindender Vorteil aller hier besprochenen Lösungen ist aber die Tatsache, dass Sie keine Speicherkapazität (NAS/ SAN) für die Aufbewahrung der Sicherungsdaten bereitstellen müssen, sowie die mit der Cloudspeicherung einhergehende geografische Trennung von Nutz- und Backupdaten.

Zur Abgrenzung zum Themenkomplex Replikation sei noch einmal betont, dass wir unter einem Backup allgemein das Sichern des Systemzustands zu einem bestimmten Zeitpunkt verstehen – definiert durch Parameter wie RTO und RPO – um eine VM oder einen Server etwa nach dem unbeabsichtigten Löschen von Daten, Konfigurationsfehlern oder Virenbefall (logische Fehler) schnell wiederherstellen zu können.

Das ersetzt keineswegs eine Replikationslösung, die je nach Konfiguration in der Lage ist, einen unterbrechungsfreien IT-Betrieb bei Ausfall von Hardwarekomponenten an der geschützten Site zu gewährleisten. Backups ersetzen ferner keine Archivierungslösung zur Langzeitaufbewahrung regulatorischer Daten, auch wenn sie bisweilen dazu missbraucht werden. Sie erlauben aber beispielsweise die situationsbedingte Rückkehr in einer isolierten Umgebung zu Nachweiszwecken. Auch wenn moderne Backupsysteme und Schnittstellen für virtuelle Maschinen im Wesentlichen auf Snapshot-Verfahren basieren, kann ein Datenträger-Snapshot einer VM allein ebenfalls nicht als Ersatz für eine vollumfängliche Sicherung gewertet werden. Nichtsdestotrotz sind Snapshots das Mittel der Wahl, um anwendungskonsistente Sicherungen von VMs (im Gegensatz zu physischen Computern) besonders einfach zu gestalten, da virtuelle Maschinen ja bereits Software sind. So erlauben moderne VM-affine Sicherungslösungen wie Veeam, das Backup direkt am Hypervisor abzuziehen, anstatt mit Agenten in den Gastsystemen arbeiten zu müssen.

Je nach Integrationsgrad mit dem Hypervisor-NAS/SAN lassen sich Backups auch auf der Storage-Ebene abgreifen, etwa mit "Veeam Direct storage access", und ermöglichen auf diese Weise LAN-freie Backups. Ferner erlauben moderne Verfahren und Protokolle wie VMwares Changed Block Tracking (CBT) schnelle inkrementelle Sicherungen. Das gilt auch für Hyper-V- und Azure-VMs. Für jeden zu sichernden Datenträger liest Azure Backup die Blöcke auf dem Datenträger, identifiziert und überträgt aber nur diejenigen Datenblöcke, die sich seit der vorherigen Sicherung geändert haben.

Zur eigentlichen Durchführung eines Backups einer VMware- oder Hyper-V-Maschine kommt also generell eine VM-Snapshot-Technologie zum Einsatz. Bei Windows-VMs findet generell Microsofts Shadow-Copy-Technologie, auch Volume Snapshot Service (VSS) genannt, Verwendung – eine Datensicherungsfunktion von Windows Server zum Erstellen konsistenter Zeitpunktkopien von Daten. Während Hyper-V (das gilt dann auch für Azure) über einen eigenen VSS-Writer verfügt, verwendet VMware seine vSphere-Data-Protection-API zum Auslösen von VMware-Snapshots. Auch Backup-Produkte von Drittanbietern verwenden stets die APIs einer dieser Umgebungen, um eine Sicherung der VM durchzuführen. Eine solche enthält dann idealerweise die Konfiguration, die VM-Snapshots und die virtuellen Festplatten, die die VM verwendet.

Auch bei Azure-VMs erstellt beispielsweise der Backupdienst von Azure stets anwendungskonsistente Momentaufnahmen der VM-Datenträger in Zusammenarbeit mit VSS. Azure Backup führt per Default immer vollständige VSS-Sicherungen durch. Protokolle der Anwendungen wie SQL Server werden zum Zeitpunkt der Sicherung abgeschnitten, um eine konsistente Sicherung auf Anwendungsebene zu erhalten.

Um App-konsistente Momentaufnahmen einer Linux-VM in Azure zu erstellen, müssen Sie allerdings das Azure-Linux-Framework für Pre- und Post-Skripte nutzen. Dieses erlaubt es, benutzerdefinierte Skripte zu schreiben und mit ihnen für Datenkonsistenz zu sorgen. Pre-Scripts werden unmittelbar vor dem Erstellen von VM-Snapshots, Post-Scripts direkt danach ausgeführt, um die Anwendungen und die Umgebung beim Erstellen von VM-Momentaufnahmen steuern zu können. So rufen Pre-Scripts etwa die APIs nativer Anwendungen auf, um E/A-Vorgänge stillzulegen und den Arbeitsspeicherinhalt auf dem Datenträger zu leeren. Das wiederum stellt wie bei VSS sicher, dass der Snapshot anwendungskonsistent ist. Post-Scripts nutzen die APIs nativer Anwendungen dagegen zur Reaktivierung von E/A-Vorgängen, damit die Anwendung nach dem Erstellen des VM-Snapshots wieder den regulären Betrieb aufnehmen kann.

Azure Backup unterscheidet also zwischen anwendungskonsistenten, dateisystemkonsistenten und crashkonsistenten Snapshots beziehungsweise Wiederherstellungspunkten. Anwendungskonsistente Sicherungen erfassen neben dem Volume auch Arbeitsspeicherinhalte und ausstehende E/A-Vorgänge und verwenden entweder einen VSS-Writer (Windows) oder Pre-/Post-Scripts (Linux), um die Konsistenz der App-Daten zu gewährleisten, bevor die Sicherung erfolgt. Dateisystemkonsistente Sicherungen hingegen bedeuten, dass eine Momentaufnahme sämtlicher Dateien gleichzeitig erstellt wird. Zu absturzkonsistenten Snapshots kommt es, wenn eine Azure-VM zum Zeitpunkt der Sicherung heruntergefahren wird. Nachfolgend schauen wir uns die einzelnen Methoden unter Azure an.

Das Verfahren über Drittanbieter mit dem Speicherziel "Azure Storage Account" macht sich zunutze, dass mit einem solchen Konto bereits ein sicherer und langlebiger Speicherdienst in der Cloud zur Verfügung steht. Dessen konfigurierbaren Replikationsmodelle (LRS, ZRS, GRS, RA-GRS, GZRS und RA-GZAR) sorgen für eine extrem hohe Verfügbarkeit zwischen 11 und 16 Neunen.

Das verwendete Replikationsmodell (nicht den Speicherkontotyp) können Sie auch später noch nach Belieben anpassen. So bieten GRS, RA-GRS und RA-GZRS per Default eine Georeplikation in die jeweilige Partnerregion, sodass für jedes geschriebene Objekt nicht drei, sondern sechs Replikate gespeichert werden. Ferner können Sie neben der standardmäßig aktivierten Verschlüsselung "at rest" mit plattformseitig erzeugten, symmetrischen Schlüsseln (256 Bit AES) auch die sichere Übertragung mittels SSL ermöglichen und die Authentifizierungsebenen, Kontoschlüssel sowie die TLS/SSL-Mindestversion konfigurieren.

Außerdem können Sie öffentliche Endpunkte unterbinden – was hier aber nicht sinnvoll ist, da Sie einen öffentlichen Endpunkt für das Sichern von lokalen oder in anderen Clouds betrie­benen VMs via REST-API zwingend benötigen. Jedes Speicherkonto ist per se öffentlich, also jeder Speicherdienst darin (Blob, File, Table, Queue) ist über seinen jeweiligen Endpunkt von überall auf der Welt beispielsweise per Rest-API ansprechbar. Wer will, kann aber mit einer Netzwerk-Firewall-ACL den Zugriff auf Azure-Vnets oder spezifische IP-Adressen beschränken:

- Blob Storage: https://<storage-account>. blob.core.windows.net

- Data Lake Storage Gen2: https://<storage-account>.dfs.core.windows.net

- Azure Files: https://<storage-account>. file.core.windows.net

- Queue Storage: https://<storage-account>.queue.core.windows.net

- Table Storage: https://<storage-account>.table.core.windows.net

Was die Verschlüsselung ruhender Daten betrifft, können Sie, statt den plattformseitig generierten Schlüssel (PMK) zu vertrauen, auch einen eigenen (kundenseitig verwalteten Schlüssel; CMK) verwenden und diesen zum Beispiel in einem Azure Key Vault erzeugen und ablegen. Sind alle Sicherheitsvoraussetzungen wunschgemäß konfiguriert, können Sie nun jedes Drittanbieter-Backupwerkzeug Ihrer Wahl verwenden, das Azure Storage als Sicherungsziel unterstützt. Das Charmante daran: Sie können die Sicherungssoftware selbst auf einer Azure-VM betreiben. Der Azure-Marketplace bietet zahlreiche Angebote dazu.

Der Nachteil eines solchen Ansatzes besteht in den Kosten. Hier haben Sie es mit drei Kostenfaktoren zu tun. Betreiben Sie den Sicherungsserver auf einer Azure-VM, fallen die üblichen Compute-Kosten für eine VM an, einschließlich der Sto-rage- (Kapazität und Transaktionen) und Datenübertragungskosten der VM. Diese erhöhen sich zudem, wenn Sie den VM-Betrieb hochverfügbar gestalten. Hinzu kommen die Lizenzkosten für die Sicherungssoftware. Diese lassen sich unter Umständen aber auch auf der Haben-Seite verargumentieren, wenn Sie bereits über eine solche Lizenz verfügen und die Sicherungslösung auf einer On-Premises-VM betreiben, um lokale Workloads sichern zu können.

Größter Kostenfaktor ist aber Azure Storage selbst. Hier bezahlen Sie grundsätzlich die Speicherkapazität – so etwa in Deutschland bei Blockblob-Storage in der Standard-Leistungsstufe mit der Zugriffsebene Cold und LRS (Local Redundancy Storage) 10 US-Dollar für 1 TByte Daten im Monat. Die Transaktionen (Schreibvorgänge und Lesevorgänge) werden mit je 0,10 Dollar pro 10.000 Vorgänge, List-Vorgänge mit 0,054 Dollar pro 10.000 Vorgänge berechnet, das Schreiben von Daten mit 0,003 Dollar pro GByte und die ausgehende Datenübertragung mit 0,010 Dollar je GByte. Was als ausgehende Datenübertragungen anfällt, wird maßgeblich durch das Einsatzszenario bestimmt. In jedem Fall kommt es bei einem Restore zu einer ausgehenden Datenübertragung. Die unterstützten Sicherungsszenarien (VM-Backup, Dateien und Ordner, Bare-Metal et cetera) hängen von der eingesetzten Sicherungssoftware ab.

Möchten Sie Azure-VMs, SQL-Server auf Azure-VMs oder SAP HANA auf Azure-Backup (Recovery Services Vault, RSV) sichern, führt kein Weg an Azure Backup beziehungsweise einem RSV vorbei. Für dieses Szenario müssen Sie keinerlei eigene Infrastruktur vorhalten. Einen solchen Recovery Services Tresor haben Sie im Azure Portal mit zwei Mausklicks erstellt. Sie brauchen nur das Abonnement, eine Ressourcen-Gruppe, einen Namen sowie die Region. Beim Sichern von Az-ure-VMs ist zu bedenken, dass der Recovery Services Tresor in der gleichen Region zu erstellen ist, in der sich auch die zu sichernden VMs befinden. In den zu sichernden Windows- oder Linux-VMs bedarf es dazu der kleinen Erweiterung VMSnapshot extension [1] beziehungsweise VMSnapshotLinux extension [2], die sich aber im Regelfall automatisch installiert, sobald Sie eine Azure-VM durch Erstellen eines Sicherungszeitplans bei Azure Backup registrieren – zumindest dann, wenn das Maschine-Image, aus dem die zu sichernde VM erstellt wurde, aus dem Azure Marketplace stammt.

Der Recovery Services Vault ist eine Speicherentität in Azure, welche Daten enthält. Im Grunde handelt es sich hierbei auch nur um eine spezielle Art von verwaltetem Speicherkonto. Die enthaltenen Daten sind beispielsweise Kopien von Daten oder Konfigurationsinformationen für virtuelle Computer, Workloads, Server oder Arbeitsstationen. Sie können Sicherungsdaten für verschiedene Azure-Dienste in solch einem Recovery Services Vault speichern, wie etwa die oben erwähnten Azure-VMs (Linux oder Windows) und Azure SQL-Datenbanken. Darüber hinaus unterstützen die Recovery-Services-Tresore auch System Center DPM (Data Protection Manager) und Azure Backup Server und vereinfachen die Organisation von Sicherungsdaten.

Im Grunde ist der Unterschied zu einem regulären Speicherkonto in Sachen Backend-Technologie gering, nur dass ein RSV ausschließlich für Sicherungsaufgaben verwendbar ist. Andere Speicherdienste gibt es hier nicht. Außerdem ist die Georeplikation im Gegensatz zu einem Speicherkonto automatisch aktiviert und lässt sich nur auf LRS setzen, solange noch keine Sicherung abgelegt wurde. Danach ist dies nicht mehr möglich beziehungsweise nur noch, wenn Sie zuvor sämtliche Sicherungsdaten löschen. Außerdem ist der Schutz vor versehentlichem Löschen (Soft Delete) automatisch aktiviert.

Befindet sich der RSV in der gleichen Region wie die zu sichernde VM, können Sie eine solche nach dem Erstellen einer Sicherungsrichtlinie mit "Hinzufügen" einfach ins Backup aufnehmen, wodurch der in der Sicherungsrichtlinie konfigurierte Zeitplan aktiviert wird. In der Sicherungsrichtlinie steht letztendlich, wie oft gesichert werden soll, wie lange die Backupdaten aufbewahrt werden oder ob der im Rahmen des skizierten Sicherungsworkflows angefertigte Snapshot für eine schnelle Widerherstellung über die RSV-GUI für bis zu fünf Tage greifbar bleiben soll, während er im Hintergrund bereits in den RSV transferiert wurde.

Haben Sie eine VM zum ersten Mal erfolgreich gesichert. steht Ihnen idealerweise nach kurzer Zeit ein anwendungskonsistenter Wiederherstellungspunkt zur Verfügung. Aus diesem können Sie sowohl eine vollständige VM als auch einzelne Dateien wiederherstellen. Insofern erübrigt sich bei einer Azure-VM das Verwenden des Azure-Recovery-Service-Agents (MARS) für Windows-VMs.

Gesichert wird aber immer die vollständige VM, da das eigentliche Backup, wie zuvor erläutert, als Snapshot direkt am Storage erfolgt und nicht aus dem Gast-OS heraus. Die erwähnte Extension kommt lediglich zum Einsatz, um in der VM die Sicherung zu signalisieren und damit beispielsweise entsprechende VSS-Eigenschaften zu aktivieren. Haben Sie manuelle Snapshots für die betreffende VM angefertigt, werden diese ebenfalls in den Recovery Services Vault übertragen.

Das Wiederherstellen einzelner Dateien funktioniert nicht, wenn für die VM beide möglichen Verschlüsselungsebenen aktiviert sind – also die plattformseitige Verschlüsselung des zugrundeliegenden Storage Accounts (SSE Storage Service Encryption mit PMK oder CMK) sowie die Azure Disk Encryption (ADE). Letztere macht sich bei Windows-Maschinen die Bitlocker-Technologie (DM-Crypt bei Linux) im Gastsystem zunutze.

Hauptvorteil aller auf dem Recovery Services Vault basierenden Sicherungsmethoden ist, dass keine separaten Transferkosten anfallen. Allerdings zahlen Sie die bei den meisten Public-Cloud-Diensten üblichen verbrauchsabhängigen Kosten.

Auf diese Weise kalkuliert Microsoft also quasi die Lizenzkosten für die Sicherungssoftware mit ein. Kosten dieser Art berechnet Redmond nach "Plänen". Für Instanzen mit weniger als 50 GByte fallen hier 5,5822 Euro/Monat je Backup an, Instanzen mit mehr als 50 GByte werden mit 11,1643 Euro im Monat berechnet.

Für die Recovery-Services-Tresore an sich zahlen Sie genau wie bei einem Speicherkonto nichts. Eine Einschränkung sei aber noch erwähnt: Die konfigurierbare Sicherungsrichtlinie lässt leider nur eine automatische Sicherung pro Tag zu, manuell können Sie eine Sicherung selbstverständlich auch öfter anstoßen.

Der Weg in die Cloud erleichtert Unternehmen vieles. Doch ein Thema bleibt ihnen nicht erspart: Das Sichern der Daten. Im ersten Teil unserer zweiteiligen Workshopserie haben wir einen Überblick zum Thema Azure-Backups verschafft. Im zweiten Teil werfen wir einen Blick auf den Azure Backup Server und die Azure Recovery Services.