Proxmox-Backup schlägt fehl: Fünf Ursachen und Fixes

Ein vzdump-Job, der nachts um 02:00 mit einem einzelnen ERROR endet, ist kein Backup. In KMU und Kommunen fällt das oft erst beim ersten Restore-Test auf. Fünf Abbruchgründe decken den Großteil der Fälle ab, und alle lassen sich am Task-Log eingrenzen.

Diagnose: Das Task-Log entscheidet

Wo der echte Fehler steht

Die GUI zeigt unter Datacenter → Task History nur die Zusammenfassung. Der vollständige Log liegt im Task-Verzeichnis des Nodes, und die letzte Zeile vor dem Abbruch nennt den Grund meist wörtlich.

ls -t /var/log/pve/tasks/ | head -5
pvesh get /nodes/$(hostname)/tasks --limit 10

Reproduzieren statt raten

Ein manueller Lauf mit denselben Optionen zeigt den Fehler sofort im Terminal:

vzdump 100 --storage backup-nfs --mode snapshot

Ursache 1: Hängender Lock auf der VM

Meldung und Hintergrund

„unable to acquire lock“ oder „VM is locked (backup)“ bedeutet: Ein abgebrochener Task hat seinen Lock nicht freigegeben, etwa nach einem Timeout auf dem Backup-Storage. Proxmox verweigert dann jeden weiteren Job für diese VM.

qm status 100
ps aux | grep vzdump
qm unlock 100

Der Unlock darf erst erfolgen, wenn wirklich kein vzdump mehr läuft. Ein Unlock während eines aktiven Jobs zerstört dessen Konsistenz.

Ursache 2: Das Backup-Ziel ist voll

Fehlerbild

„job failed with err -28 ‘No space left on device’“ kommt nicht vom Gast, sondern vom Ziel-Storage. Betroffen sind häufig NFS-Freigaben mit zu langer Aufbewahrung.

pvesm status
df -h /mnt/pve/backup-nfs

Aufräumen und begrenzen

Prune-Regeln im Job, etwa keep-daily 7 und keep-weekly 4, begrenzen den Platzbedarf automatisch. Wichtig: auch Fleecing-Images belegen Platz auf dem Quell-Storage und können dort den Job abbrechen lassen. Wer Fleecing nutzt, sollte es gezielt setzen:

vzdump 100 --fleecing enabled=1,storage=local-lvm

Ursache 3: Modus passt nicht zum Storage

Container brauchen Snapshots

Bei Containern setzt der Snapshot-Modus voraus, dass alle eingebundenen Volumes auf einem Storage mit Snapshot-Unterstützung liegen. Reines LVM, CIFS oder einfache Verzeichnis-Storages fallen durch, der Job bricht mit einem Hinweis auf fehlende Snapshot-Fähigkeit ab.

cat /etc/pve/storage.cfg | grep -E '^[a-z]|content|thinpool'

Lösung ist entweder der Suspend-Modus für den Container oder die Migration der Volumes auf LVM-thin oder ZFS. Bei VMs ist der Live-Backup-Modus dagegen storage-unabhängig, er funktioniert auch auf Storage ohne Snapshot-Support.

Ursache 4: Guest Agent fehlt oder Freeze scheitert

Konsistenz statt Abbruch

Im Snapshot-Modus friert Proxmox das Gastdateisystem kurz ein, damit die Sicherung konsistent ist. Ohne laufenden QEMU Guest Agent entsteht nur ein crash-konsistentes Image; antwortet der Agent nicht rechtzeitig, bricht vzdump mit einer Guest-Agent-Meldung zum Freeze ab.

qm agent 100 ping

Fehlt die Antwort, Agent in der VM installieren (qemu-guest-agent unter Linux, virtio-win-guest-tools unter Windows) und in den VM-Optionen auf „Enabled“ stellen. Danach den Job wiederholen.

Ursache 5: NFS- oder CIFS-Timeouts

Wenn das NAS schweigt

„got timeout reading communication packets“ im Kernel-Log heißt: Das Ziel antwortet nicht mehr. Ursachen sind überlastete NAS, Link-Flaps oder ein volles Journal während des Backup-Fensters.

dmesg -T | grep -i -E 'nfs|cifs'
pvesm status

Prüfen: Erreichbarkeit des NAS, MTU bei VLAN-Trunks und die Auslastung im Backup-Zeitfenster. CIFS- und NFS-Storages sollten über die GUI verwaltet werden, nicht per manuellem fstab-Eintrag, sonst überschreibt Proxmox die Mount-Optionen nicht konsistent.

Nach dem Fix: Restore stichprobenartig testen

Ein grüner Job ist noch kein Beweis. Mindestens ein Gast pro Storage sollte monatlich zurückgespielt werden, am besten auf eine separate VMID, damit die Produktion unberührt bleibt.

qmrestore /mnt/pve/backup-nfs/dump/vzdump-qemu-100-2026_11_01-02_00_03.vma.zst 900 --storage local-lvm

Der Dateiname folgt dem Muster vzdump-qemu-VMID-Datum-Zeit.vma.zst, für Container lautet das Gegenstück vzrestore. Wer nur den Exit-Code prüft, übersieht beschädigte Archive.

Fazit

Die meisten fehlgeschlagenen Jobs scheitern an Platz, Locks oder einem unpassenden Storage-Modus, nicht an Proxmox selbst. Wer das Task-Log liest und monatlich einen Restore testet, erkennt Ausfälle, bevor der Ernstfall eintritt.

Quellen

• Proxmox VE Wiki: Backup and Restore (Backup-Modi, Fleecing, Retention) (abgerufen 01.11.2026)
• Proxmox VE Documentation: Backup and Restore (vzdump) (abgerufen 01.11.2026)
• Proxmox VE Documentation: Storage (Snapshot-Fähigkeit, LVM-thin, NFS/CIFS) (abgerufen 01.11.2026)
• Thomas-Krenn-Wiki: Kategorie Proxmox VE (abgerufen 01.11.2026)

Hinweis: Dieser Beitrag wurde mit Unterstützung künstlicher Intelligenz (KI) erstellt.