Tägliches fehlschlagen der Backups wegen Timeout

[Erdnussflip1812]

Guten Morgen,

unsere Backups schlagen schon seit Wochen fast täglich fehl, da es immer wieder einen "230: 2026-08-12 07:14:28 ERROR: Backup of VM 230 failed - VM 230 qmp command 'backup' failed - got timeout" gibt. Unser Ceph welches ich auch mal unter voller Last getestet habe langweilt sich gefühlt, wenn die Backups laufen. Zudem habe ich jetzt die Backup entzerrt, so das jeder Node nach einander erst startet. Ich habe unter vzdump.conf ebenfalls die Priorität sehr hoch gestellt zwischen 1-3. Die Maschinen die dort fehlschlagen sind sowohl Windows als auch Linux Maschinen.

Ich hoffe man kann mir mal einen pest-practice guide liefern in der Hoffnung das ich dort noch fündig werde was ich noch einstellen könnte.

 

[Supaman]

Mein Cluster ist zwar etwas kleiner, aber Grundsätzlich ähnliches Setup:
3 Node Ceph CLuster, ca 30 VMs
externer PBS

Der Backup Job ist all-in-one: sichere alle VMs um 22:30h auf PBS. Kein Finetuning nötig, fertig, läuft.
Wenn alle 3 Nodes gleichzeitig sichern, hängt es vom PBS ab, wie schnell der die Daten annehmen (Netzwerk) und wegschreiben kann.
Je nach Datenmenge bzw Änderungen seit letztem Backup ist dann der eine oder andere Node früher fertig.

Ich würde an folgender Stelle ansetzen:
1) Mach mal separates Backup von VM 230
2) Schau auf dem PBS nach, wie die Auslastung ist und ob ob noch andere Jobs gleichzeitig laufen

Das splitten der Backup Jobs halte ich nicht für unnöig, weil: der Backup Job arbeitet die VMs einen nach dem anderen ab -> max. Datentransfer möglich und es gibt keine Überschneidungen mit anderen Jobs. Wenn z.B. mehrere Jobs durch Fehlkonfiguration die selben Elemente sichern sollen, kann es zu blockierungen führen, wenn ein job noch nicht abgeschlossen ist, und der nächste startet.

 

[Erdnussflip1812]

Alles klar, also was ich bestätigen kann es hat nichts damit zu tun ob meine 7 server gleichzeitig auf dem Ceph schreiben oder nicht, es hat viel mehr damit zu tun das der Agent das Backup auf der VM NICHT starten kann oder halt kurz nach der Timeout Frist erst...Ich würde tippen wenn ich den Timeout erhöhen könnte auf 2 Minuten gefühlt dann läuft jede Maschine ordentlich durch, aber der Agent schafft es nicht seinen DIENST in der kurzen Zeit zu vollrichten...

 

[Supaman]

es hat viel mehr damit zu tun das der Agent das Backup auf der VM NICHT starten kann oder halt kurz nach der Timeout Frist erst...

Es gibt in dem Sinne keinen "Agent", und keinen Agent der ein Backup startet. Vereinfachte Darstellung: der PVE Backup Prozess liest die Datenblöcke vom PVE Storage, verschlüsselt diese ggf. und überträgt die Blöcke an den PBS. Für ein Backup wird innerhalb der VM kein Agent benötigt. Das ist ja das schöne an der Kombination von PVE-PBS, da wird das Backup direkt vom Hypervisor angefertigt.

 

[Erdnussflip1812]

Es gibt in dem Sinne keinen "Agent", und keinen Agent der ein Backup startet. Vereinfachte Darstellung: der PVE Backup Prozess liest die Datenblöcke vom PVE Storage, verschlüsselt diese ggf. und überträgt die Blöcke an den PBS. Für ein Backup wird innerhalb der VM kein Agent benötigt. Das ist ja das schöne an der Kombination von PVE-PBS, da wird das Backup direkt vom Hypervisor angefertigt.

oh, alles klar, dankeschön. Aber weshalb können manche Backups grundlegend nicht starten oder bekommen diesen qmp command timeout?

 

[Erdnussflip1812]

ist es denn möglich einen retry einzustellen also das er den timeout 3 mal z.B. feststellen müsste, dass er es als "failed" einstuft.