Backup mit Veeam und Microsoft Azure

In dieser Artikelreihe möchte ich näher auf die verschiedenen Möglichkeiten eingehen, die Veeam in Verbindung mit Microsoft Azure bietet. Darunter fallen unter anderem:

• Veeam Cloud Tier – Backups auslagern zu Microsoft Azure
• Direct Restore nach Microsoft Azure
• Veeam Backup for Microsoft Azure
• Azure VM Instant Recovery nach On-Prem vSphere
• Azure VM Backup Copy nach On-Prem
• Veeam Backup for Microsoft Office 365 in Azure

Diese Blog Posts sollen einen Überblick bieten und den Einstieg in die Thematik erleichtern. Es handelt sich um eine kleine Starthilfe mit Demo/PoC Charakter. Best Practices zu dem einen oder anderen Thema folgen später noch. Stay tuned …

Voraussetzung – Azure Storage Account

Um Microsoft Azure als künftiges Ziel unserer Backups nutzen zu können, müssen wir zuerst einen Storage Account, falls noch nicht vorhanden, erstellen.

Hierzu im Azure Portal auf „Create resource“ klicken.

Im Suchfeld „Storage account“ eingeben und auswählen.

Ein Klick auf „Create“ startet den Konfigurationsassistenten.

Zuerst wählt man hier die gewünschte „Subscription“ und „Resource group“ aus. Falls noch keine Resource group vorhanden ist, oder aus organisatorischen Gründen eine neue verwendet werden soll, kann diese mit „Create new“ erstellt werden.

Unter „Storage account name“ vergibt man einen global einmaligen Namen und wählt unter „Location“ die gewünschte Region aus. Die restlichen Settings wählt man den eigenen Anforderungen entsprechend. Nähere Erläuterungen zu den einzelnen Optionen findet man am Ende des Artikels. Weiter mit „Next : Networking“.

Unter „Connectivity method“ gibt man an, von wo aus bzw. aus welchen Netzen auf den Storage Account zugegriffen werden kann. Hier wählt man die passende Option. Nähere Erläuterung der einzelnen Optionen am Ende des Artikels. Weiter mit „Next : Advanced“.

Auf dem „Advanced“-Reiter kann man die Voreinstellungen so übernehmen wie sie sind. „Secure transfer required“ würde ich auf jeden Fall auf „Enabled“ belassen, um die Backups über HTTPs verschlüsselt zu übertragen. Die restlichen Einstellungen sind für unsere Zwecke unerheblich. Weiter zu „Tags“.

Die Tags lasse ich in diesem Fall leer, allerdings könnten sie in einer Produktivumgebung z.B. für das Kostenmangement und die Zuordnung zu Kostenstellen, Abteilungen, Services, etc. recht hilfreich sein. Weiter mit „Next : Review + create“.

Unter „Next : Review + create“ erhält man eine Zusammenfassung der gewählten Optionen bzw. der getätigten Einstellungen. Unter Umständen kann man nochmals Anpassungen vornehmen und wenn die Validierung anschließend erfolgreich ist, mit einem Klick auf „Create“ den Storage Account erstellen.

Nach dem das Deployment abgeschlossen ist, kann man mit „Go to resource“ zum eben erstellten Storage Account wechseln.

Um dort Dateien oder in unserem Fall Backups speichern zu können, muss zuerst noch ein Container erstellt werden. Dazu auf „Containers“ klicken.

Mit „+ Container“ wird der New container Assistent geöffnet.

Dort vergibt man einen Namen und wählt das „Public access level“ aus. Ich entscheide mich hier für „Private (no anonymous access)“ und somit für ausschließlich authentifizierten Zugriff über Access Keys. Es stünden zwar auch noch „Blob (anonymous read access for blobs only)“ und „Container (anonymous read access for containers and blobs)“ zur Wahl, aber da der Container als Ziel unserer Backups dienen soll, macht hier anonymer Zugriff definitiv keinen Sinn. Ein Klick auf „Create“ erstellt den Container.

An dieser Stelle ist alles Notwendige vorhanden um den Storage Account als Backup Repository verwenden zu können. Zur Einrichtung als Backup/External/Cloud Repository unter Veeam benötigen wir zur Authentifizierung noch die Access Keys. Dazu unter „Settings“ auf „Access keys“ klicken.

Zur anschließenden Konfiguration unter Veeam werden der „Storage account name“ und einer der beiden Keys „key1“ oder „key2“ benötigt. Aus Sicherheitsgründen wird empfohlen die Access keys regelmäßig neu zu erstellen. Deshalb stehen auch zwei Keys zur Verfügung. Während der erste Key neu generiert wird, ist der Zugriff nach wie vor über den zweiten gegeben.

Erläuterung

Location

Die Wahl der Region hängt von einigen Faktoren ab. Zum einen spielt oftmals die geografische Nähe aufgrund von Latenzen eine Rolle und zum anderen müssen meist auch rechtliche und Compliance Anforderungen beachtet werden, also dass z.B. Daten nur in Deutschland oder Europa gespeichert werden dürfen. Die Azure Regionen unterscheiden sich auch hinsichtlich Kosten und verfügbarer Features. So kann es z.B. gut möglich sein, dass ein bestimmtes VM Image in einer bestimmten Region erheblich teurer ist, als in einer anderen, oder dass für einen Storage Account nicht alle Replication Modes (s. unten) zur Verfügung stehen.

Aus Kostengründen und da dort im Normalfall auch alle Features zur Verfügung stehen, entscheide ich mich für North Europe.

Performance

Folgende Optionen stehen zur Wahl:
Standard = HDD, niedrigsten Kosten pro GB, für große Datenmengen mit seltenem Zugriff
Premium = SSD, geringe Latenz, NUR für Azure VM Disks

Die Auswahl kann nachträglich nicht mehr geändert werden.

Nähere Informationen s. hier.

Da wir den Storage Account als Backupspeicher verwenden wollen, bleibt hier nur die Wahl von „Standard“.

Account kind

Folgende Optionen stehen zur Wahl:
StorageV2 (general purpose v2):
– neuere Variante des allgemeinen Accounts
– geeignet für Blobs, Dateien, Queues, Tabellen, Disks, Data Lake Gen2
– unterstützt Standard und Premium
– unterstützt Tiering
– unterstützt alle Replikationsmodi

Storage (general purpose v1):
– ältere (legacy) Variante des allgemeinen Accounts
– erhält keinen neuen Features mehr
– geeignet für Blobs, Dateien, Queues, Tabellen, Disks
– unterstützt Standard und Premium
– unterstützt kein Tiering
– unterstützt nur LRS, GRS, RA-GRS
– Konvertierung zu GPv2 möglich

BlobStorage:
– nur für Blob Blocks und Append Blobs geeignet
– unterstützt nur Standard
– unterstützt Tiering
– unterstützt nur LRS, GRS, RA-GRS
– Konvertierung zu GPv2 möglich

Empfehlung von Microsoft: StorageV2 nutzen.

Nähere Informationen s. hier.

Ich folge hier der Empfehlung von Microsoft und entscheide mich für StorageV2, um sowohl alle neuen Features nutzen zu können, als mir auch eine gewisse Flexibilität in der Nutzung des Accounts offen zu lassen.

Replication

Folgende Optionen stehen zur Wahl:
Locally-redundant storage (LRS):
3 Kopien, synchron, an einem physischem Standort in der primären Region, schützt vor Hardware- und Rackausfall
Zone-redundant storage (ZRS):
3 Kopien, synchron, auf 3 Availability Zones verteilt, in der primären Region, schützt vor Ausfall einer Availability Zone
Geo-redundant storage (GRS):
wie LRS, zusätzlich erfolgt asynchrone Kopie an einen physischen Standort in einer sekundären Region
Geo-zone-redundant storage (GZRS):
wie ZRS, zusätzlich erfolgt asynchrone Kopie an einen physischen Standort in einer sekundären Region
Read-access geo-redundant storage (RA-GRS):
wie GRS, zusätzlich lesender Zugriff auf Daten in sekundärer Region
Read-access geo-zone-redundant storage (RA-GZRS):
wie GZRS, zusätzlich lesender Zugriff auf Daten in sekundärer Region

Hinweise:
– einige Einstellungen können nach Erstellung des Storage Accounts nicht mehr geändert werden
– Sekundäre Region hängt von der Wahl der primären ab und ist nicht frei wählbar
– In sekundärer Region erfolgt Speicherung mit LRS
– bei GRS und GZRS Zugriff auf Kopie in sekundärer Region nur nach Ausfall und Failover der primären Region möglich
– Der Replikations-Traffic zwischen den Zonen und Regionen verursacht zusätzliche Kosten.
– Die Verfügbarkeit der Replikationsmodi hängt von der gewählten Region und vom Account Typ ab (s. oben).
– Prinzipiell gilt: höhere Verfügbarkeit = höhere Kosten

Nähere Informationen s. hier.

Für meine Test-/Demo-Zwecke reicht hier LRS vollkommen aus.

Access tier

Folgende Optionen stehen zur Wahl:
Hot = optimiert für häufigen Zugriff
Cool = optimiert für seltenen Zugriff, Speicherdauer min. 30 Tage, günstigere Speicher- aber höhere Zugriffskosten als bei Hot

Hinweise:
– Archive Access Tier kann nur auf Blob- nicht auf Storage Account-Ebene gesetzt werden, Speicherdauer min. 180 Tage, günstigste Speicher- aber höchste Zugriffskosten, Offline-Speicherung, Zugriff auf Daten kann Stunden dauern
– Access Tier kann bei Upload oder auch nachträglich noch geändert werden
– bei Cool und Archive fallen zusätzliche Gebühren an, wenn Daten vor Ablauf der Mindestspeicherdauer gelöscht werden

Nähere Informationen s. hier.

In einer Produktivumgebung würde ich „Cool“ verwenden. Da es sich in meinem Fall jedoch nur um eine Test-/Demo-Umgebung handelt und ich schnell Zugriff auf die Backups haben möchte, wähle ich „Hot“.

Connectivity method

Folgende Optionen stehen zur Wahl:
Public endpoint (all networks) = öffentlicher Zugriff über Public IP aus ALLEN Netzen auch aus dem Internet
Public endpoint (selected networks) = öffentlicher Zugriff über Public IP aus definierten Azure Virtual Networks (VNets)
Private endpoint = Zugriff über private IP und privaten Link über VNets auch von On-Prem über ExpressRoute oder VPN

Nähere Informationen s. hier.

Prinzipiell sollte man die Zugriffe auf den für die Backups verwendeten Storage Account natürlich bestmöglich absichern und nur aus definierten, privaten Netzen erlauben z.B. auch über ExpressRoute und/oder VPN. Zumindest aber sollte der Public Access auf eine bestimmte Public-IP bzw. einen Public IP-Bereich beschränkt werden. Für meine Test-/Demo-Zwecke verwende ich allerdings bewusst „Public endpoint (all networks)“, da ich weder eine statische Public IP habe, noch ExpressRoute oder VPN. Allerdings lasse ich keinen anonymen Zugriff zu, sondern verwende ausschließlich Authentifizierung über Access Keys.