Azure VM Instant Recovery nach On-Prem vSphere

In diesem Teil der Artikelreihe „Backup mit Veeam und Microsoft Azure“ möchte ich demonstrieren, wie man mit Veeam Backup for Microsoft Azure gesicherte VMs schnell und unkompliziert per Instant VM Recovery auf eine On-Premises vSphere Umgebung wiederherstellen kann. Möglich macht dies Veeam Backup & Replication Version 10. Derzeit ist diese Funktion nur für vSphere verfügbar, weitere Optionen sollen jedoch folgen.

Voraussetzungen:

• Veeam Backup for Microsoft Azure (ab Free Edition)
• Backups auf Azure Blob Repository
• Veeam Backup & Replication v10 (ab Community Edition)
• Einbinden des External Repositorys
• eine VMware vSphere Umgebung als Ziel (ab Version 5.5)
• vCenter Server oder standalone ESXi Host – kein Free ESXi!

Einrichtung des External Repositorys

In der Veeam Backup & Replication Console wählt man unter „BACKUP INFRASTRUCTURE“ „External Repositories“ aus. Mit einem Klick auf „Add Repository“ startet man den Konfigurations-Assistenten.

Im Assistenten wählt man „Veeam Backup for Microsoft Azure“ aus.

Als erstes wählt man für das External Repository einen Namen aus. Die „Description“ ist dabei optional. Weiter mit „Next >“.

Entweder wählt man unter „Credentials“ einen bereits vorhanden Account aus, oder erstellt mit „Add“ neue Zugangsdaten.

Unter „Account“ wird der Name des Storage Accounts angegeben und unter „Shared key“ einer der beiden Access Keys. In das Feld „Description“ sollte eine eindeutige Beschreibung eingegeben werden. Dies ist hier mehr als sinnvoll, denn sollte sich z.B. einmal ein Key ändern, so weiß man sofort welcher hier verwendet wurde und ob durch die Änderung irgendwelche Auswirkungen zu erwarten sind. Eingabe mit „OK“ abschließen.

Weiter mit „Next >“.

An dieser Stelle wählt man den entsprechenden „Container“ aus und mit „Browse…“

den dazugehörigen Ordner.

Sollte man mit Veeam Backup for Microsoft Azure verschlüsselte Backups erstellt haben, so kann man dies hier konfigurieren. Für meine Demo-/Test-Zwecke habe ich mich allerdings für unverschlüsselte Backups entschieden und fahre mit „Apply“ fort.

Jetzt wird die Konfiguration in der Datenbank gespeichert und das Repository angelegt und eingebunden.

Unter „Summary“ erhält man noch eine kurze Zusammenfassung und beendet mit einem Klick auf „Finish“ den Assistenten.

Die Einrichtung des External Repositorys ist damit abgeschlossen.

Instant VM Recovery zu VMware

Nach dem Einrichten des External Repository wechselt man in der Veeam B&R Console zu „HOME“ und wählt dort unter „Backups“ „External Repository“ aus. Auf der rechten Seite werden in der Übersicht dann alle Backup Jobs angezeigt, die sich auf External Repositories befinden.

Anmerkung:
Sollte ein kürzlich angelegter Job fehlen oder nicht der aktuellste Restore Point angezeigt werden, dann bitte einen Rescan des External Repository durchführen: „BACKUP INFRASTRUCTURE“ -> „External Repositories“ -> betreffendes Repository auswählen -> Rescan

Hier wählt man den gewünschten Job aus, klappt das Untermenü auf und selektiert die zu wiederherstellende VM. Neben „Instant VM recovery…“ hat man auch noch die Möglichkeit Guest Files (Windows und Linux) zu restoren, Disks der VM zu exportieren oder einen Restore zu AWS EC2 oder Azure durchzuführen, wobei Azure in diesem Fall eher sinnfrei wäre.

Ein Klick auf „Instant VM recovery…“ öffnet den Restore Assistenten. Standardmäßig ist der aktuellste Restore Point vorausgewählt. Möchte man die VM zu einem anderen, früheren Zeitpunkt wiederherstellen, so kann man dies unter „Point“ anpassen. Mit „Add“ oder „Remove“ lassen sich weitere VMs des Backup Jobs hinzufügen oder aber entfernen.

Unter „Restored VM name“ könnte man auch einen Zusatz wie z.B. „_restored“ anfügen, aber da sich die Original-VM in einer völlig anderen Umgebung befindet, lasse ich den Namen unverändert. „VM folder“, „Resource pool“ und „Networks“ können aber müssen nicht angepasst werden. Im Fall von „Networks“ macht dies aber mehr als Sinn, da man hier bereits das virtuelle Zielnetzwerk für die wiederhergestellte VM auswählen kann.

Nach der Auswahl des Zielhosts passe ich noch den „VM Folder“ und „Networks“ an, den Rest belasse ich wie er ist.

Unter Advanced hätte man eigentlich die Möglichkeit die „BIOS UUID“ beizubehalten, was in diesem Fall (Azure -> vSphere) nicht möglich und deshalb auch nicht verfügbar ist. Weiter mit „Next >“.

Standardmäßig werden während der Instant VM Recovery Laufzeit geänderte Blöcke in den vPower NFS Cache Ordner des im Backup Repository konfigurierten Mount Servers geschrieben. vPower NFS wird übrigens nur für Instant VM Recovery zu VMware genutzt. Mit „Redirect write cache“ kann dies aber auch angepasst werden. In meinem Fall ist der Mount Server der B&R Server vbr02 selbst und der Default Cache Ordner ist unter „C:\ProgramData\Veeam\IRCache\“ zu finden. Ich belasse es bei den Standard-Einstellungen und mache mit „Next >“ weiter.

Mit „Secure Restore“ wäre es möglich, vor dem Restore der VM noch einen Scan nach Malware wie z.B. Viren oder Ransomware durchführen zu lassen. Voraussetzung hierfür ist eine auf dem Mount Server des Backup Repositorys installierte Antiviren-Software wie z.B. Windows Defender. Dies funktioniert allerdings nur mit Windows VMs. Für meine Demo bzw. Tests spare ich mir dies jedoch.

Unter „Restore reason“ kann man noch einen Grund für die Wiederherstellung angeben, muss man aber nicht. Bei mir würde dieser Grund „Demo“ lauten, deshalb weiter mit „Next >“.

Unter „Summary“ wird zum einen eine kurze Zusammenfassung der getätigten Settings angezeigt und zum anderen kann man hier mit „Connect VM to network“ und „Power on target VM after restoring“ noch festlegen, ob die VM NIC mit der gewählten Portgruppe verbunden werden soll und ob man die VM auch gleich starten will. Die Warnung kann ich in meinem Fall getrost ignorieren, da ich keinerlei L2 VPN usw. zu Azure habe und deshalb auch keine IP-, Namens- oder sonstige Konflikte auftreten können. Mit „Finish“ wird der Vorgang gestartet.

Nach erfolgreichem Abschluss des Restores kann man das „Restore session“ Fenster schließen und findet auf der linken Seite der Veeam B&R Console einen neuen Punkt „Instant Recovery“.

Dort wird die aus dem Azure Backup wiederhergestellte mit Status „Mounted“ angezeigt.

Das Resultat sieht dann nach einiger Zeit (nicht vergessen das Backup liegt immer noch in Azure) so aus.

Und man kann sich mit den in Azure vergebenen VM Credentials anmelden.

Ergänzung Standalone Host:
Wählt man als Wiederherstellungsziel einen Standalone ESXi Host aus, so muss man im Instant Recovery Assistenten noch zusätzlich die Netzwerkeinstellungen der für die V2V Konvertierung zuständigen Helper Appliance über „Configure…“ definieren.

Mit „Browse…“ wird die Portgruppe bzw. das Netzwerk ausgewählt, in dem sich auch der B&R Server befindet und entscheidet sich entweder für dynamische (DHCP Server erforderlich!) oder statische IP und DNS Einstellungen. Diese bestätigt man mit „OK“ und setzt den Assistenten mit „Next >“ fort.

Nacharbeiten

Nach dem Login wird man erst einmal von einigen (Fehler-) Meldungen begrüßt. Neben der Frage warum der Computer unvorhergesehen neu gestartet wurde (war aufgrund des Starts aus dem Backup heraus auch so zu erwarten), wird auch noch gefragt ob man denn im Netzwerk sichtbar sein will (was bestätigt das die VM über DHCP eine IP erhalten hat).

Zur Behebung der temporären Paging File Thematik die Meldung mit „OK“ bestätigen und

im nachfolgenden „Performance Options“ Fenster unter „Virtual memory“ auf „Change“ klicken und

den Haken bei „Automatically manage paging file size for all drives“ setzen und mit „OK“ bestätigen. Den Hinweis zum benötigten Neustart ebenfalls mit „OK“ bestätigen.

Den geforderten Neustart kann man idealerweise gleich mit dem Abschluss der VMware Tools Installation kombinieren, die die Bedienung & Performance erheblich verbessern und im vSphere Client auch dafür sorgen, dass alle VM Informationen korrekt angezeigt werden.

Ergänzung zu Azure Linux VMs:
Bei meinen Tests habe ich auch eine in Azure betriebene Ubuntu 18.04 VM erfolgreich nach On-Prem vSphere per Instant VM Recovery wiederhergestellt.

Die VM hat über DHCP eine IP bezogen, auch schon die Open-VMware Tools mit an Bord und ich konnte mich über SSH erfolgreich anmelden.

Evtl. sollte man sich aber überlegen, ob man nicht auch schon in Azure neben der SSH Pub-Key Variante auch noch einen Login mit sudo-Rechten und Passwort versieht. Sollte nämlich beim Restore der VM ein Netzwerk-Problem auftreten und die VM per DHCP keine IP ziehen, so hat man KEINERLEI Zugriffsmöglichkeit.

Denn ohne Passwort ist auch keine Anmeldung an der VM Console möglich!

Abschluss

In der Veeam Console unter „Home“ „Instant Recovery“ stehen einem neben „Open VM Console“ (öffnet wie der Name schon sagt ein Konsolenfenster) und „Properties“ (zeigt eine Zusammenfassung der Restore Session inkl. Parameter und Log) auch die Optionen „Migrate to Production“ und „Stop Publishing“ zur Verfügung.

Migrate to Production

Mit „Migrate to Production“ kann man die wiederhergestellte VM über einen Assistenten in den Produktivbetrieb übernehmen. Im Assistenten lassen sich mit „Choose…“ die jeweiligen Ziele für „Host or cluster“, „Resource pool“, „VM folder“ und „Datastore“ festlegen. Weiter mit „Next >“.

An dieser Stelle könnte man beim Vorhandensein mehrerer Proxies, idealerweise einer in jeder beteiligten Site, den nächstgelegenen auswählen. Ich belasse es hier aber beim Standard „Automatic selection“. „Force Veeam transport usage“ würde trotz vorhandenem und lizenziertem Storage vMotion anstelle die Veeam Engine (Quick Migration) zur Migration nutzen. Auch hier bleibe ich aber beim Default und verlasse mich auf vMotion.

Nach einer kurzen Validierung „Checking the possibility of migration…“ wird eine Zusammenfassung angezeigt. Die Option „Delete source VM files upon successful migration“ sollte gesetzt bleiben, da nach der Übernahme der VM in den Produktivbetrieb auch automatisch die Instant VM Recovery Session beendet wird. Andernfalls müsste man diese später selbst manuell beenden. Start und Abschluss des Vorgangs mit „Finish“.

Am Ende hat man eine Instant Recovery VM weniger, dafür aber eine mehr in der Produktivumgebung :-).

Hinweis:
Alternativ zu „Migrate to Production“ kann die VM auch direkt über den vSphere Client mit Storage vMotion verschoben und die Instant VM Recovery Bereitstellung mit „Stop Publishing“ beendet werden.

Stop Publishing

Um nach abgeschlossenen Tests, etc. die Bereitstellung der VM über Instant VM Recovery einfach wieder zu beenden wählt man die VM aus und im Anschluss die Option „Stop Publishing“.

Fertig!