Veeam Backup und MOB-ID

Jede VM auf einem ESX Server erhält bei Erstellung oder Import eine interne Kennung, die so genannte MOB-ID oder MoRefID. Diese lautet ‘vm-‘ gefolgt von einer Zahl. Zum Beispiel vm-25 oder vm-74. Diese ID ist innerhalb eines vCenters einzigartig und wird in der vCenter Datenbank gespeichert. Über diese ID referenziert Veeam Backup die zu sichernde VM zum Backup. Das ist prinzipiell in Ordnung, sorgt aber für Probleme wenn z.B. eine VM aus dem Backup wiederhergestellt wird. In diesem Fall wird die Backup-VM unter altem Namen neu im vCenter registriert und erhält eine neue MOB-ID. Welche Konsequenz hat dies für den nächsten Backuplauf? Veeam wird die VM nicht mehr finden und das nächste Backup wird fehlschlagen.

Ein Beispiel

Eine Veeam Sicherungsjob enthält eine VM namens “Dummy” und diese hat die MOB-ID “vm-15”. Nach einem Recovery wird die VM “Dummy” wieder im vCenter registriert, erhält aber eine neue MOB-ID “vm-1271”. Im Backupjob ist aber die VM Dummy weiterhin unter ID “vm-15” registriert, welche nach dem Recovery nicht mehr existiert. Das Backup scheitert.

Backup Amnesie

Ganz schlimm wird es, wenn bestehende ESXi Server einem neuen vCenter beitreten. Zum Beispiel beim Wechsel vom Windows vCenter zur vCenter Appliance (VCSA). Für das Backup bedeutet ein solcher Schritt, dass alle VMs aus dem bestehenden Job entfernt und wieder hinzu gefügt werden müssen (wegen neuer ID). Beim nächsten Durchlauf des Backups erfolgt eine Vollsicherung, da Veeam die bestehenden VMs im Backup nicht mit den IDs der gleichnamigen VMs korrelieren kann. Je nach Größe der Infrastruktur kann dies zu erheblichen Zeitproblemen beim Backupfenster führen.

Das müsste so nicht sein, denn jede VM hat zusätzlich eine einzigartige UUID. Diese ändert sich weder bei Recovery, noch bei dem Beitritt zu einem neuen vCenter. Leider verwendet Veeam Backup weiterhin die nicht eindeutige MOB-ID – möglicherweise aus historischen Gründen.

Manuelle Reparatur

Man kann diesem Umstand korrigieren, indem man die Veeam Datenbank manipuliert.

Achtung! Die hier beschriebene Methode wird nicht von Veeam empfohlen und es besteht auch kein Anspruch auf Support. Anwendung auf eigene Gefahr!

Die Tabelle BObjects in der Veeam Backup Datenbank enthält alle vom Backup verwalteten VMs. In der Spalte Object_id findet man die MOB-ID der zu sichernden VMs. Die Test-VM hatte zunächst die ID vm-1579. Die VM wurde vom vCenter gelöscht und mit Veeam Backup wiederhergestellt. Dadurch erhielt sie eine neue ID, von der Veeam aber keine Kenntnis hat.

MOB-ID ermitteln

Zur ermittelung der MOB-ID gibt es mehrere Möglichkeiten. Eine davon ist mittels Managed Object Browser (MOB).

https://vcenter.mydomain.com/mob

Der Managed Object Browser ist etwas verwirrend. Man findet die MOB-ID der VM aber über folgenden Pfad:

content > rootFolder > child entity > vmFolder > childEntity (VM-Folder) > vm MOB-ID

 

 

 

 

 

 

 

Nummer hinter dem Datacenter kann abweichen.

 

 

Falls die VMs in Unterordner organisiert sind, so ist unter childEntity der entsprechende Folder zu wählen (hier: Discovered virtual machine).

 

Die VM, die hier exemplarisch betrachten hat im MOB die ID vm-1745. Sie wurde nach dem letzten Veeam Backup wiederhergestellt.

 

Schauen wir nun, unter welcher ID diese VM in der Veeam Datenbank gelistet ist, so sehen wir noch die ursprüngliche ID vm-1579.

 

In der Tabelle BObjects ist die VM weiterhin inter Object_id vm-1579 referenziert. Die Folge ist, dass das Backup im nächsten Durchlauf scheitern wird.

 

 

QED 🙁

Hack by Hand

Eine quick-and-dirty Methode ist, diese ID manuell in der Tabelle BObjects zu ändern. Also vm-1579 durch vm-1745 zu ersetzen. Das funktioniert für eine oder zwei VMs, ist aber bei einem Cluster sehr mühsam und fehleranfällig.

Powershell

Besser ist hier der Ansatz mit PowerCLI. Das folgende Skript wurde von meinem Kollegen Yannic Hamann erstellt und leicht modifiziert. Erste Tests waren erfogreich.

Warnung: Für diese Methode gibt es keinerlei Freigabe durch den Veeam Support. Benutzung auf eigene Gefahr!

Veeam_RelinkVM

Nach Ausführung des PowerCLI Skriptes wurde die object_id für VM ‘Microbase’ aktualisiert.

Ein erneuter Durch lauf des Backup bringt danach keine Fehlermeldung mehr.

Frage an Veeam

Die Berechtigte Frage an Veeam wäre nun, warum man als Referenz nicht anstatt der object_id (=MOB ID) die uuid verwendet, welche für die VM einzigartig ist und auch nach Export und Import erhalten bleibt.