Probleme Veeam-Backup und Proxmox Hypervisor – Veeam Worker startet nicht bzw. Errors

[VirtuSage]

Hallo zusammen,

wir setzen in unserer Umgebung Proxmox als Hypervisor und Veeam als Backup-Software ein.
Aktuell haben wir derzeit ein Problem, bei dem der Veeam Worker nicht korrekt funktioniert. (beim Starten bzw. Initialisieren)
Backupjobs werden gestartet, allerdings wird der Veeamworker nicht erreicht oder ist noch in einem vorherigen Prozess. (Fehlermeldungen in den Anhängen als Bilder)

Folgende Historie...
Zu Beginn wurden keine Backups mehr durchgeführt, der Job schlug fehl mit der Meldung, dass der Veeam Worker nicht erreicht werden konnte. In Proxmox war die VM des Veeam Workers noch im Startprozess (generating cloud-init ISO) und konnte nicht hochfahren. Ein manuelles Abbrechen der VM führte dazu, dass der nächste Backup-Vorgang erfolgreich verlief.
Ein weiterer Fehler trat auf, nachdem wir den Prozess über die Konsole beendet hatten: Proxmox zeigte an, dass die VM noch "in use" war, da ein Lock-File gesetzt war. Wir benannten das Lock-File um, damit die VM wieder startete. Seitdem wurde ein neues Lock-File erzeugt, und die VM scheint nicht mehr gestartet zu werden.
Veeam zeigt den Fehler "Timeout waiting on systemd" an.

Veeam 12.3.0.310
pve-manager/8.3.2/3e76eec21c4a14a7 (running kernel: 6.8.12-5-pve)

Nächster Plan war, den VeeamWorker einmal manuell zu starten, ob sich die VM überhaupt noch starten lässt.

Leider konnten wir das Problem bisher nicht lösen, und die Sicherungen laufen nicht mehr bzw. wenn nicht zuverlässig.
Hat jemand von euch ähnliche Erfahrungen gemacht oder eine Lösung bzw. Vorschlag parat?
Über jede Hilfe oder weiterführende Hinweise wären wir sehr dankbar!

Vielen Dank im Voraus!

VirtuSage

 

[PParker]

Wo liegt die VM und was zeigt deren Konsole?

 

[VirtuSage]

Hallo zusammen,

die VeeamWorker-VM befindet sich auf einem TrueNAS-Storage mit einem NFS-Share, auf dem auch die anderen virtuellen Maschinen laufen. Ich habe die vorherige Lockfile zurückgeschoben, aber der VeeamWorker lässt sich weder vor, noch nach dem Zurückschieben manuell starten. Ich vermute, dass der VeeamWorker entweder beschädigt wurde oder noch Prozesse am Laufen sind, die den Zugriff auf die Lockfile blockieren.

Leider komme ich auch nicht in ein Konsolenfenster, ich habe nur den Fehler beim starten via GUI.

Ich überlege, den Proxmox-Server neu zu starten, allerdings laufen darauf mehrere VMs, die ich nicht einfach herunterfahren kann. Ein Versuch wäre, die VM zu klonen und die vorherige zu löschen, falls noch Prozesse im Hintergrund laufen. Hat jemand Erfahrung mit dieser Vorgehensweise oder eine bessere Idee, wie ich das Problem lösen kann, ohne die VMs auszuschalten?

 

[GMBauer]

Das Problem mit dem Start des Veeam Clients ist aber ein bekanntes. Liegt m.E. an einem normalen Ubuntu-Update, das der Client nicht vertragen hat. (Dies aber nur imho!)

Das sollte mit dem neuesten Veeam-Update behoben worden sein.

Ich fürchte aber, dass man das künftig genau beobachten muss. Imho ist die langjährige Zuverlässigkeit und Unfehlbarkeit von Veeam, die wir vom ESXi her kannten und schätzten, unter Proxmox nicht mehr gegeben. Ich beobachte das jetzt noch ein wenig, werde aber eventuell alles zum PBS migrieren.

 

[ceelight]

Bei uns liegt dieses Problem auch vor, daher Danke für das Öffnen des Threads. Sowohl @VirtuSage als auch wir nutzen die neuste Version 12.3.0.310 vom Dezember. Eine neuere gibt es Stand heute nicht, oder?

@VirtuSage den Lock kann man evtl. mit qm unlock <VM-ID> beheben, oder?

 

[Falk R.]

Ich hatte das Problem auch schon. Ich habe die Worker gelöscht und neu erzeugt, dann geht es erst einmal wieder. Ist aber nicht ganz Nachhaltig.

 

[VirtuSage]

Hallo zusammen,

ja.. wir sind explizit auf die aktuellste Veeam-Version gegangen, als die Probleme entstanden sind.
Ein Update brachte bei uns keinen Erfolg.

@GMBauer
Eine neuere Version von Veeam ist mir nicht bekannt.
(Muss man vielleicht den VeeamWorker auch neuinstallieren nach einem Veeam-Update?)

@ceelight
Danke für den Tipp, habe ich gerade versucht, die VM bzw. das lockfile hat wohl was abbekommen....
"can't lock file '/var/lock/qemu-server/lock-100.conf' - got timeout"

Ich versuche noch einen Clonevorgang des Workers als "Workarround".

@Falk R.
Ja, darauf wird es bei uns vermutlich hinauslaufen, dann wird man sehen, ob man die VeeamWorker nach Veeam-Update neu einrichten muss,
nachhaltig ist das ganze wirklich nicht.

Schonmal vielen Dank für die Unterstützung.

 

[VirtuSage]

Hallo zusammen,

hier schon mal für die Nachwelt:

Der Workaround mit dem Klonvorgang hat leider nichts gebracht, auch hier gab es keinen Zugriff auf die Lock-Datei.
Ich konnte den Worker nicht einmal aus Veeam löschen!

Ich musste die Lock-Datei manuell umbenennen und durch manuelles Starten neu generieren lassen.
Danach konnte ich den Worker aus Veeam löschen.

Es scheint, dass sich der Worker nach dem Veeam-Update nicht automatisch aktualisiert.
Eine Funktion wie „Worker aktualisieren“ lässt sich nicht finden.

Aktuell lassen sich die Backups nach neuer Einrichtung des Veeam-Workers erneut durchführen.
Mal schauen, ob das Problem mit dem Worker( neueingerichtet) in der aktuellen Veeam-Version weiterhin besteht.