Neulich wollte ich bei einem Kunden einen SureBackup Job in Veeam Backup & Replication einrichten. Mit SureBackup lassen sich Backups automatisch auf ihre Wiederherstellbarkeit testen. So kann bspw. ein Microsoft Exchange Server geprüft werden ob dessen Backup im Falle eines Restores auch sauber ist und überhaupt wiederhergestellt werden kann. Die Einrichtung des SureBackup Jobs soweit sehr gut funktioniert. Nur der anschliessende Testlauf wollte nicht wie geplant funktionieren.
In Veeam erstellt man zuerst eine Application Group und ein Virtual Lab. Die Application Group umfasst alle für den Test notwendigen VMs. So werden bspw. für einen Microsoft Exchange Server sicher mal die VM für Exchange benötigt, aber auch ein Domaincontroller. Man fügt also die entsprechenden VMs zur Application Group hinzu und definiert auf diesen VMs die passenden Rollen (DNS, DC, Mail etc.). Abhängig von diesen Rollen werden die entsprechenden Tests vom SureBackup Job automatisch ausgeführt. Das Virtual Lab umschreibt prinzipiell das Netzwerk und die Einstellungen, mit welchen die VMs im SureBackup Job arbeiten. Anschliessend wird mit der Application Group und dem Virtual Lab ein SureBackup Job eingerichtet.
Das hat alles einwandfrei funktioniert. Der SureBackup Job konnte ausgeführt werden, die erste VM wurde erfolgreich gestartet und auch der Heartbeat-Test (VMware) war erfolgreich. Doch egal wie lange die VM lief, Veeam konnte sie nicht pingen. Das ist noch nicht tragisch, man könnte diesen Test auch deaktivieren. Jedoch ist dann der Restore nicht zwingend erfolgreich, wenn bspw. Probleme mit der Netzwerkschnittstelle vorhanden sind. Mit dem Ping-Test können diese allenfalls herausgefunden werden. Nachdem die maximale Boot-Zeit für die Domaincontroller VM abgelaufen war wurde der Test als “failed” beendet.
Also zurück ans SureBackup Reissbrett und schauen wo der Fehler liegt
Das Virtual Lab ist noch etwas mehr als bloss die Netzwerkeinstellung für die VMs die getestet werden. Das Lab beinhaltet auch eine eigene virtual Appliance welche Routingfunktionen bietet. Normalerweise hat ein Virtual Lab, welches man aus Veeam heraus startet, keine Netzwerkverbindung nach draussen ins Internet. Das kann mit dieser virtual Appliance aber konfiguriert werden. So können diverse Virtual Labs erstellt werden, welche bspw. auch länger verfügbar sind als nur für einen Restore-Test. So kann man Virtual Labs und Sandboxen erstellen welche für Patch-Testing und Development gebraucht werden können.
Schlussendlich war das Problem eines auf Netzwerkebene
Damit Veeam die VMs im Virtual Lab anpingen kann, müssen die Netzwerkeinstellungen der virtual Appliance korrekt sein. Wenn nach dem ersten Deployment und anschliessenden Testlauf der Test fehlschlägt können vielleicht die folgenden Tipps helfen damit die Tests nachher funktionieren:
Bei mir war es der zweite Punkt (“VNIC FOR ISOLATED NETWORK MISCONFIGURED”). Mein Virtual Lab hatte eine falsche IP-Adresse, aus einem Netzwerkrange den es bei diesem Kunden nicht gibt. Das Virtual Lab sollte als eigene IP-Adresse immer die IP Adresse des Default Gateways haben, damit oben erwähnte Ping-Tests funktionieren.
Keine Panik, es ergibt sich daraus kein IP-Konflikt. Die virtual Appliance selbst bekommt von eurem DHCP-Server eine IP-Adresse. Da das Lab ein in sich geschlossenes Netzwerk ist ohne Verbindung nach draussen spielt das Virtual Lab hier die Rolle des Gateways für die VMs im Lab.
Falls ihr mehr zum Thema SureBackup Jobs wissen wollt und solche eure Backups zukünftig automatisch testen lassen wollt, erfährt ihr im Veeam HelpCenter mehr dazu:
Veeam HelpCenter – Verifying Backups, Replicas and VMs from Storage Snapshots
Ich wünsche euch viel Spass beim Konfigurieren und Testen eurer Backups!