Proxmox VE: vzdump-Fehler (STATUS=failed) beheben

Das Problem: vzdump bricht ab

Ein Backup ist nur so gut wie seine Wiederherstellung. Wenn vzdump in Proxmox VE jedoch mit Fehlercodes wie STATUS=failed oder EKEYEXPIRED abbricht, steht man oft vor einem Rätsel. Besonders in Umgebungen mit hybriden Storage-Backends (lokaler ZFS + entfernter NFS/CIFS-Speicher) treten komplexe Abhängigkeiten auf, die nicht sofort ersichtlich sind.

Basierend auf typischen Incident-Reports und der offiziellen vzdump-Dokumentation finden Sie hier die fünf häufigsten Ursachen und die konkrete Behebung.

1. Der klassische Speicherfall: „Disk quota exceeded“

Die häufigste Ursache ist schlichtweg Platzmangel. Doch Vorsicht: Bei ZFS-Pools zeigt df -h oft noch freien Platz an, während die Quota des spezifischen Dataset bereits voll ist.

Check:

zfs get used,avail quota <pool>/vms

Abhilfe: Löschen Sie alte Backups (< 7 Tage) manuell oder erweitern Sie die Quota. Ein schneller Befehl zum Bereinigen alter Snapshots:

pvesm free <storage-id>

2. EKEYEXPIRED: Das SSH-Zertifikat des Backup-Ziels

Wenn Sie Backups auf einen externen Server (SSH/SCP) schreiben, trat in der Vergangenheit oft der Fehler EKEYEXPIRED auf. Dieser kommt zustande, wenn das automatische Schlüsselpaar für den Transfer abläuft oder das Zielsystem seinen known_hosts-Eintrag gelöscht hat.

Diagnose: Testen Sie die Verbindung manuell vom PVE-Host aus:

ssh -o BatchMode=yes root@<backup-server> "mkdir -p /backups"

Lösung: Fügen Sie den Host-Key erneut hinzu oder prüfen Sie, ob ein Zertifikat auf dem Zielsystem ungültig wurde. Stellen Sie sicher, dass der pvebackup-User (oder root) kein abgelaufenes Kennwort hat, falls interaktiv gefordert.

3. Blockierende Locks: „Another backup is currently running“

Proxmox erlaubt standardmäßig keine parallelen Backups derselben VM, um Datenkonsistenz zu gewährleisten. Wenn ein Langzeit-Backup einer großen VM läuft, blocked das System zeitweise andere Tasks.

Check: Listet die aktiven Tasks auf:

pve tasks list --status running

Tipp: Konfigurieren Sie Ihre Jobs (GPO-ähnlich im web-UI unter „System“ -> „Cron Jobs“) so, dass sie sich zeitlich nicht überschneiden. Nutzen Sie das mode snapshot, um Live-Backups ohne Downtime durchzuführen, aber beachten Sie die I/O-Last.

4. COW-Snapshots und defekte Disks

Beim Backup wird ein QEMU-Monitor-Snapshot erstellt. Wenn der underlying Storage (z.B. eine NFS-Freigabe) kurzzeitig nicht erreichbar ist, kann der Snapshot hängen bleiben. Dieser „zombie“ Snapshot blockiert anschließend das nächste Backup.

Check:

qm list <VM-ID>

Suchen Sie in der Ausgabe nach Spalten wie Snapshots. Ist diese Liste ungewöhnlich lang oder zeigt sie Fehler an, hilft oft ein manuelles Entfernen:

qm disk snapshot <VM-ID> <disk> delete

5. Falsche Berechtigungen auf dem Ziel-Storage

Bei lokalen NFS- oder CIFS-Mounts, die nicht über die Proxmox Storage-UI, sondern manuell in der /etc/fstab eingehängt wurden, fehlen oft die Schreibrechte für den User root im Kontext des Containers (pveproxy oder vzdump).

Abhilfe: Nutzen Sie besser den integrierten Proxmox Storage-Manager („Datacenter“ -> „Storage“). Dort werden die Rechte korrekt für den pve-User eingestellt. Bei manuellen Mounts prüfen Sie:

chown -R www-data:www-data /pfad/zum/backup
chmod -R 770 /pfad/zum/backup

Fazit

Backup-Fehler in Proxmox lassen sich in den meisten Fällen auf drei Kategorien reduzieren: Speicherplatz, Locks oder Netzwerk-/Rechteprobleme. Nutzen Sie den Befehl vzdump --mode snapshot <VM-ID> für einen manuellen Testlauf mit ausführlicher Logausgabe (--verbose), um die Ursache genau zu isolieren.

Haben Sie weitere typische vzdump-Fehler? Teilen Sie Ihre Lösungen in den Kommentaren.