Von null / 30 Sep 2020 / Themen: Microsoft Azure Cloud Backup Wiederherstellung
mindestens 3 Kopien der Daten, auf 2 verschiedenen Medien und 1 davon an einem externen Speicherort
Die Einrichtung des External Repositorys habe ich bereits ausführlich an anderer Stelle beschrieben und verweise deshalb auf den Artikel „Azure VM Instant Recovery nach On-Prem vSphere„. Neben dem External Repository muss außerdem eine Veeam Backup & Replication Enterprise Plus Lizenz vorhanden sein.
In der Veeam B&R Console wählt man unter „HOME“ „Jobs“ aus, klickt im Menüband auf „Backup Copy“ und anschließend auf „Azure IaaS…“.
Daraufhin öffnet sich der „New Backup Copy Job“ Assistent. Neben „Name“ und „Description“ lässt sich unter „Copy mode“ noch das Copy Intervall „Copy every“ von „Periodic copy (pruning)“ anpassen. „Immediate copy (mirroring)“ ist ausgegraut, da dieser Modus nur bestimmte Backup Typen unterstützt und Veeam Backup for Microsoft Azure gehört nicht dazu. In der Voreinstellung beginnt das Intervall täglich um Mitternacht. Nach dem Start wird überprüft ob neue Restore Points vorhanden sind und falls ja, wird der aktuellste während des Intervalls einmalig kopiert. Falls nein, wartet der Job im Status „Idle“ auf die Erstellung eines neuen Restore Points. Ich belasse hier den Default und gehe mit „Next >“ weiter zu „Objects“.
Mit einem Klick auf „Add…“ kann man entweder ganze Jobs, oder aber einzelne VMs, des zuvor konfigurierten External Repositorys, auswählen. Entscheidet man sich für einen Job werden nur Restore Points, die auch von diesem erzeugt wurden, kopiert. Bei Auswahl einzelner VMs werden alle erstellten Restore Points, auch die anderer Jobs, berücksichtigt.
Ich wähle den kompletten Job und füge ihn über „Add“ hinzu.
Weiter mit „Next >“.
Unter „Target“ wählt man als erstes das gewünschte „Backup repository“ als Ziel aus.
Ich verwende hier das bereits vorhandene Scale-Out Backup Repository „SOBR 01“ mit Azure Cloud Tier d.h. aus Azure herauskopierte Backups werden später wieder nach Azure ausgelagert – hat ein bißchen was von einer Endlosschleife und würde in einer Produktivumgebung nur unnötige zusätzliche Kosten verursachen – für Test-/Demo-Zwecke aber ok.
Über „Map backup“ könnte auch ein bereits vorhandener Seed (s. hier) verwendet werden und somit das initiale Full Backup entfallen – ist in diesem Szenario aber eigentlich eher unwahrscheinlich.
Mit „Restore points to keep:“ legt man fest wieviele Restore Points vorgehalten werden sollen und trifft somit auch die Entscheidung über die Länge der Forever Forward Incremental Kette.
Durch „Keep the following restore points as full backups for archival purposes“ lässt sich für Archiv-Zwecke eine GFS (Grandfather-Father-Son) Backup-Strategie umsetzen. „Read the entire restore point from source backup instead of synthesizing it from increments“ würde die GFS Full Backups direkt vom Quell Repository (Azure External Repository) lesen („Active Full“), anstelle die bereits On-Prem vorhanden Restore Points („Synthetic Full“) zu verwenden.
Ich entscheide mich hier für 30 Restore Points und eine GFS Strategie mit 4 wöchentlichen, 12 monatlichen und 1 jährlichen Full Backup.
Mit „Schedule“ lässt sich festlegen, wann genau die wöchentlichen, monatlichen, quartalsweisen oder jährlichen GFS Full Backups erstellt werden. Ich übernehme die Voreinstellungen und bestätige mit „OK“.
Die „Advanced“-Einstellungen enthalten nur einen Teil der bei regulären On-Prem vSphere oder Hyper-V Backup Jobs zur Verfügung stehenden Optionen.
Am interessantesten dürfte der Punkt „Maintenance“ sein. Dort lassen sich zum einen unter „Storage-level corruption guard“ regelmäßige Health-Checks und zum anderen unter „Full backup file maintenance“ Wartungsaufgaben wie defragmentieren oder komprimieren der Backup Files planen. Bei Verwendung von GFS („Keep the following restore points as full backups …“) zur Erstellung regelmäßiger Full Backups entfällt die Notwendigkeit zur geplanten Defragmentierung und Komprimierung (s. Hinweis gelber Kasten), weshalb nur die Option „Remove deleted items data after … days“ (Bereinigung nicht mehr vorhandener VMs) konfigurierbar ist.
Ansonsten kann man unter „Storage“ die Voreinstellungen zu „Data Reduction“ (Dedup und Komprimierung) und „Encryption“, unter „Notifications“ die Benachrichtigungen (E-Mail und SNMP) und unter „Scripts“ das Ausführen von Pre-/Post-Skripts anpassen bzw. aktivieren. Ich lasse die „Advanced Settings“ unverändert und bestätige sie mit „OK“. Mit „Next >“ geht es weiter zum vorletzten Punkt des Assistenten „Schedule“.
Mit „Schedule“ kann man mit „Any time (continuously)“ und „During the following time periods only:“ festlegen zu welchen Zeiten der Kopiervorgang über das Netzwerk erlaubt sein soll und dadurch Beeinträchtigungen des Produktivbetriebs vermeiden. Ich schließe hier den Zeitraum Montag – Freitag von 7:00 – 17:59 Uhr aus. Weiter mit „Apply“.
Mit „Enable the job when I click Finish“ wird der Backup Copy Job direkt nach Beendigung des Assistenten ausgeführt. Abschluss mit Klick auf „Finish“.
Unter „HOME“ „Jobs“ findet man in der B&R Console nun einen zusätzlichen Menüpunkt „Backup Copy“ und darunter den gerade angelegten und aktiven Copy Job. Wählt man diesen aus, so öffnet sich in der unteren Bildschirmhälfte das Statusfenster. Aufgrund des zuvor konfigurierten Schedules, darf der Job im Moment nichts kopieren „Waiting for permitted network usage period“ und beide VMs stehen auf „Pending“.
Sobald der „erlaubte“ Zeitraum beginnt, startet der Backup Copy Job den Kopiervorgang. In dem hier vorliegenden Fall wurde ein initiales Full Backup der beiden VMs innerhalb von ca. 37 Minuten parallel kopiert/erstellt. Die Gesamtlaufzeit von 2 Stunden und 28 Minuten ergibt sich aufgrund der Wartezeit („Waiting for permitted …“).
Nach der ersten erfolgreichen Ausführung des Copy Jobs, erscheint in der B&R Console unter „HOME“ „Backups“ ein zusätzlicher Menüpunkt „Disk (Copy)“. Dort kann man sich einen Überblick über die vorhandenen Backup Kopien inkl. der Restore Points verschaffen. Mit einem (Rechts-) Klick auf eine der VMs stehen einem die üblichen Optionen wie z.B. „Instant VM recovery…“, „Restore guest files“, „Restore to …“, usw. zur Verfügung.
Während eingehende Datenübertragen (inbound Traffic) zu/nach Azure kostenlos sind, fallen für outbound Traffic Gebühren an. Dies würde natürlich auch auf das obige Szenario zutreffen.
Autor: Oliver Grassl, Insight Solution Architect
Erstveröffentlichung unter https://www.justalittleb.it/2020/07/12/azure-vm-backup-copy-nach-on-prem/
