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.

 

[gipp]

Ich habe ein Proxmox Cluster mit drei Servern.
Veeam in der neuesten Version.
Auf dem ersten von den dreien bleibt der Worker immer wieder hängen. Also im Prinzip das gleiche, wie oben beschrieben.
Bei den anderen beiden passiert das bisher nicht.
Den Worker vom ersten Server habe ich auch schon mal entfernt und neu erzeugt. Nach einer Weile kam der Fehler wieder.
Mit

systemctl status qemu.slice

überprüfe ich jeden Morgen, ob der Worker wieder hängen geblieben ist.
Der Worker hat bei mir die ID: 101.
Wenn der wieder hängt, stoppe ich den Worker mit:

systemctl kill 101.scope

Die Lock-Datei wird dabei nicht gelöscht.
Mit:

rm /var/lock/qemu-server/lock-101.conf

kann die Datei nach dem "Abschuss" des Workers gelöscht werden.
Nach ein paar Tagen kommt der gleiche Fehler wieder.
Also auch, wie oben erwähnt, alles nicht besonders nachhaltig.

 

[Falk R.]

- Musst du wirklich jedes mal den kill ausführen? Das musste ich bisher nie.
- Die VM bleibt natürlich gelockt beim killen, dann einfach qm unlock #ID ausführen

 

[gipp]

Ich kann das gerne beim nächsten Mal mit "unlock" probieren.
Bisher war das "killen" die einzige Möglichkeit für mich.

 

[gipp]

Und schon habe ich das Problem wieder.
Und der Test mit qm unlock 101 endet mit Fehler

root@pve01:~# qm unlock 101
trying to acquire lock...
can't lock file '/var/lock/qemu-server/lock-101.conf' - got timeout

Danach habe ich den Worker wieder mit kill abgeschossen.
Mit qm unlock 101 dann den Versuch unternommen die Lock-Datei zu entfernen
Keine Fehlermeldung, aber die Lock-Datei bleibt erhalten.
Also wiede von Hand entfernen
Morgen, nach dem Versuch des Backups, weiß ich mehr.

 

[gipp]

Und wieder ist der Worker hängen geblieben.
Jetzt habe ich den über VEEAM noch einmal entfernt. Dazu musste ich den vorher wieder "abschießen".
Neu angelegt.
Mal sehen, ob das Backup dann funktioniert.
Das wird richtig nervig gerade.

 

[Falk R.]

Hast du an der VM irgend etwas anders, als bei den anderen Workern?

 

[gipp]

Im Prinzip nichts besonderes.
Veeam meldet bei 3 von 6 VMs entweder ein Warning oder einen Error.
Der Error tritt bei einer Windows Server Maschine mit Windows 2019 Server auf.
Der zweite Error bei einer "alten" Windows 2003 Server-Maschine.
Der Warning bei einem Windows Server 2022.
Gesamtmeldung für den ersten Versuch zum Backup:

Failed to prepare the worker VMWorker-PVE01: Failed to power on the worker VM: Failed to wait for the task UPIDve01:00044F50:002BEE0F:67EEFE8F:qmstart:101:root@pam: to complete; TKOVA-AA : An unknown Proxmox VE error has occurred; There are no available workers in the cluster pve01. Performance may be affected; TS2019 : An unknown Proxmox VE error has occurred; Job finished with error at 4/3/2025 11:53:11 PM

Der "TKOVA-AA" ist der alte Windows 2003 Server.
Beim zweiten Versuch für das Backup durch Veeam:

TKOVA-AA : An unknown Proxmox VE error has occurred; Failed to prepare the worker VMWorker-PVE01: Failed to synchronize configuration settings of the worker VMWorker-PVE01 can't lock file '/var/lock/qemu-server/lock-101.conf' - got timeout; There are no available workers in the cluster pve01. Performance may be affected; Job finished with error at 4/4/2025 12:10:32 AM

Wahrscheinlich ist der Worker schon beim ersten Versuch hängen geblieben.
Der dritte Versuch für das Backup durch Veeam:

Failed to prepare the worker VMWorker-PVE01: Failed to synchronize configuration settings of the worker VMWorker-PVE01 can't lock file '/var/lock/qemu-server/lock-101.conf' - got timeout; There are no available workers in the cluster pve01. Performance may be affected; TKOVA-AA : Failed to perform backup: Failed to prepare disks for backup; Unable to determine the amount of free space for the snapshot storage on rbdool0; Job finished with error at 4/4/2025 12:26:26 AM

Die anderen VMs vom ersten PVE wurden sauber gesichert.
Auf dem dritten PVE habe ich sogar noch ältere Maschinen. Eine sogar noch mit XP und eine mit Windows7. Da läuft aber die Sicherung über Veeam.

Erwähnenswert ist vielleicht noch, dass ich alle VMs von einer VMWare Umgebung zu Proxmox migriert habe.
Für die nächste Sicherung durch Veeam lasse ich jetzt mal die eine VM, die Schwierigkeiten macht, mal weg. Zur Not versuche ich ein getrenntes Backup durch Proxmox selbst.

 

[Falk R.]

Auch wenn da nix besonderes sein soll, sind es manchmal Kleinigkeiten, die einen Unterschied machen.
Check mal wie die Konfiguration des Worker aussieht, ob da irgend etwas anders ist und auf welchem Datastore laufen die Worker? Typ und wie voll.

 

[gipp]

Alle drei sind auf einem CEPH Pool. Alle drei auf dem gleichen.
Da die Worker alle drei von Veeam angelegt werden, ist die Wahrscheinlichkeit groß, dass die Konfig gleich ist. Ich habe auf jedem der Server einen Worker. Aber alle drei sind auf dem CEPH Pool abgelegt.
Auf dem Pool ist noch mehr als genug Platz. Belegung von 17% ist wirklich nicht viel.

 

[Falk R.]

Alle drei sind auf einem CEPH Pool. Alle drei auf dem gleichen.
Da die Worker alle drei von Veeam angelegt werden, ist die Wahrscheinlichkeit groß, dass die Konfig gleich ist. Ich habe auf jedem der Server einen Worker.

Leider ist dem nicht immer so. Ich hatte schon eine VM mit etwas anderer Konfiguration. Die eine wurde aber später nach einem Veeam Update zusätzlich angelegt. Daher meine Frage.