Proxmox vzdump backup failed : 10 causes réelles et comment vérifier dans l’ordre

Procédure de diagnostic rapide (vérifier 1/2/3)

Quand une sauvegarde échoue, il y a deux objectifs : (1) récupérer une sauvegarde réussie aujourd’hui, et (2) empêcher la récurrence sans transformer votre fenêtre de sauvegarde en projet de week-end. Le chemin le plus rapide est généralement : logs → santé/capacité du stockage → capacité de snapshot → transport (NFS/CIFS/PBS) → permissions/verrous.

Vérification 1 : trouver le point d’échec exact dans le log

Ne commencez pas à « réparer le stockage » au hasard. Obtenez le premier message d’erreur précis et le contexte autour.

cr0x@server:~$ ls -1t /var/log/vzdump/*.log | head
/var/log/vzdump/qemu-101.log
/var/log/vzdump/lxc-203.log

cr0x@server:~$ tail -n 80 /var/log/vzdump/qemu-101.log
INFO: starting new backup job: vzdump 101 --storage backup --mode snapshot --compress zstd
INFO: filesystem type on dumpdir is 'nfs'
INFO: creating vzdump archive '/mnt/pve/backup/dump/vzdump-qemu-101-2025_12_26-02_00_01.vma.zst'
ERROR: vzdump archive creation failed: write error: No space left on device
INFO: Backup job finished with errors
TASK ERROR: job errors

Décision : Si vous voyez une erreur concrète comme No space left on device, Permission denied, Input/output error, stale file handle, snapshot failed, arrêtez-vous et suivez cette branche. Si vous ne voyez que ERROR: Backup of VM 101 failed - vma: ... sans cause, passez à la section « Tâches » ci‑dessous et lancez les vérifications plus approfondies.

Vérification 2 : confirmer que le stockage cible est inscriptible, monté et pas plein

cr0x@server:~$ pvesm status
Name         Type     Status           Total            Used       Available        %
local         dir     active       102400000        12233456        90016644    11.94%
backup        nfs     active      2048000000      2039000000         9000000    99.56%
local-lvm     lvmthin active        500000000       310000000       190000000    62.00%

Décision : Si backup est à 99–100% ou montre un espace disponible anormalement faible, considérez-le comme plein. Libérez de l’espace ou corrigez les quotas/réservations avant toute autre manipulation.

Vérification 3 : l’échec est-il lié au snapshot ou au transport ?

Les échecs en mode snapshot sont bruyants et immédiats. Les échecs de transport (NFS, PBS, disques lents) ressemblent à des timeouts, « broken pipe » ou tâches « gelées ».

cr0x@server:~$ grep -E "snapshot|freeze|thaw|qmp|lvm|zfs|ceph|rbd|stale|timeout|broken pipe|i/o error" -i /var/log/vzdump/qemu-101.log | tail -n 30
ERROR: vzdump archive creation failed: write error: No space left on device

Décision : Les mots-clés liés au snapshot vous orientent vers les vérifications du driver de stockage local (LVM-thin/ZFS/Ceph) et de l’agent invité. Les mots-clés de transport vous orientent vers le réseau NFS/PBS et la santé/capacité côté serveur.

Faits et contexte intéressants (pourquoi ça échoue ainsi)

• vzdump est antérieur aux configurations modernes « PBS-first » de Proxmox. Il a commencé comme un simple outil de dump et a évolué en moteur de workflow qui coordonne snapshots, gel/dégel et archivage.
• Les sauvegardes par snapshot sont d’abord une fonctionnalité du stockage, ensuite une fonctionnalité Proxmox. Si le backend ne peut pas snapshotter de façon fiable (ou manque d’espace métadonnées), vzdump ne peut pas « faire fonctionner » la sauvegarde.
• L’intégration avec le QEMU guest agent est optionnelle, mais les conséquences ne le sont pas. Sans agent, vous obtenez toujours une sauvegarde crash-consistent, mais les applications (bases de données) peuvent être mécontentes.
• VMA est le format d’archive VM de Proxmox. Il est simple et rapide, mais pas magique : il dépend de lectures stables depuis les volumes VM et d’écritures stables vers le stockage cible.
• NFS est populaire pour le stockage de sauvegarde car il est « facile », ce qui en fait aussi un point de défaillance fréquent : stale handles, montages soft, retransmissions, et le syndrome du « ça marchait hier ».
• Les snapshots ZFS sont peu coûteux ; les envois ZFS ne le sont pas. L’explosion de snapshots et la fragmentation des datasets peuvent transformer silencieusement une sauvegarde nocturne en incident de performance.
• La metadata pool de LVM-thin est une chose séparée que vous pouvez remplir. Quand la metadata thin atteint 100%, vous n’« échouez pas en douceur ». Vous vous arrêtez.
• La compression change la forme des I/O. zstd est généralement un avantage, mais si votre nœud est lié par le CPU ou si votre stockage cible est lent, la compression peut aggraver les timeouts.
• Proxmox utilise des fichiers de verrou et des logs de tâches pour éviter le chaos des sauvegardes doubles. Quand un nœud redémarre en plein job, ces verrous peuvent survivre et provoquer des échecs secondaires.

10 causes réelles de « vzdump backup failed » (dans l’ordre où je vérifie)

1) Le stockage cible est plein (ou effectivement plein à cause de quotas/réservations)

Ceci est le coupable ennuyeux le plus courant. Ce n’est pas toujours « 100% plein ». Les exports NFS peuvent avoir des quotas par répertoire. Les datasets ZFS peuvent avoir des reservations. Les datastores PBS peuvent atteindre des limites de GC de chunks. Le symptôme depuis vzdump est généralement « write error » ou « No space left on device ».

Vérifier : utilisez pvesm status en premier lieu, puis vérifiez sur le chemin monté avec df -h. Si c’est NFS, vérifiez aussi côté serveur. Si c’est PBS, contrôlez l’utilisation du datastore et les paramètres de prune.

2) La cible de sauvegarde n’est pas montée ou est montée incorrectement (chemin NFS/CIFS changé, course d’automount)

Si /mnt/pve/backup n’est pas en réalité votre partage NFS au moment du job, vzdump écrit silencieusement dans le répertoire local derrière le point de montage (ou échoue s’il est absent). C’est ainsi que vous « remplissez mystérieusement » le stockage local alors que les sauvegardes « échouent ».

Vérifier : mount, findmnt, et confirmer que les options de montage sont sensées (mount hard pour les sauvegardes, pas soft).

3) La création de snapshot échoue (mode incompatible avec le type de stockage, ou le stockage ne peut pas snapshotter maintenant)

Les sauvegardes en mode snapshot nécessitent coopération : snapshots LVM-thin, snapshots ZFS, ou snapshots Ceph RBD. Si vous êtes sur du stockage de type « directory » sans support de snapshot, le mode snapshot ne fera pas ce que vous pensez. Si vous êtes sur LVM-thin mais que la metadata thin est presque pleine, les snapshots échouent quand vous en avez le plus besoin.

Vérifier : les logs pour des erreurs « snapshot », vérifier le type de stockage avec pvesm status/pvesm config, et inspecter la santé de LVM-thin/ZFS/Ceph.

4) Verrou bloqué ou état de tâche résiduel bloque le job

Perte de courant, reboot de nœud, incident de stockage — tout ce qui interrompt une sauvegarde peut laisser des verrous. Ensuite, la tentative suivante échoue immédiatement avec des erreurs « locked ». Proxmox protège vos disques VM contre des sauvegardes concurrentes ; il vous rend service, bruyamment.

Vérifier : liste des tâches et fichiers de verrou ; aussi confirmer que la VM n’exécute pas effectivement déjà une sauvegarde.

5) Instabilité du transport NFS/CIFS (stale file handles, mapping de permissions, timeouts)

Les échecs NFS sont rarement polis. Vous obtenez « stale file handle », « permission denied », « input/output error » ou « server not responding ». CIFS/SMB offre sa propre palette : rotation d’identifiants, bizarreries de dialecte et verrous de fichiers étranges.

Vérifier : logs kernel (dmesg), options de montage, retransmissions, et logs côté serveur. Si votre réseau perd des paquets, votre système de sauvegarde devient un déni de service distribué envers votre patience.

6) Problèmes côté PBS datastore (permissions, datastore plein, prune/GC qui n’arrive pas, échecs de vérification)

Sauvegarder vers Proxmox Backup Server est en général plus robuste que des partages fichiers bruts, mais les échecs existent : datastore plein, mismatch de namespace/permissions, token expiré, ou contentions verification/GC pendant la fenêtre de sauvegarde.

Vérifier : les logs du nœud Proxmox montreront des erreurs d’auth/HTTP ; PBS montrera des erreurs du datastore et du chunk store. Ne devinez pas — confirmez côté PBS.

7) Problèmes QEMU Guest Agent / freeze-thaw provoquant blocage ou timeout de snapshot

Quand vous demandez un snapshot cohérent, Proxmox utilise le QEMU guest agent pour geler les systèmes de fichiers. Si l’agent est absent, obsolète ou bloqué, vous pouvez voir des timeouts de freeze. Si vous forcez, vous risquez des sauvegardes « fonctionnelles » mais des restaurations problématiques.

Vérifier : statut QMP/agent, rechercher des messages « fsfreeze », et confirmer le service agent à l’intérieur de la VM.

8) Erreurs de lecture sur les disques VM (erreurs checksum ZFS, Ceph dégradé, SSD en fin de vie)

Une sauvegarde lit chaque bloc alloué. C’est pourquoi les sauvegardes détectent souvent un stockage défaillant avant vos utilisateurs. Si les lectures échouent, vzdump abandonne. Le vrai coupable est sous Proxmox : erreurs ZFS, soucis mdadm, secteurs SMART en attente, ou problèmes de PG Ceph.

Vérifier : ZFS zpool status, données SMART, santé Ceph, et erreurs I/O kernel.

9) Goulots de performance (CPU, IO wait, fenêtre de sauvegarde trop courte) provoquent timeouts ou chevauchement de jobs

Les sauvegardes qui échouent pour cause de « timeout » sont souvent un problème d’ordonnancement déguisé en problème technique. Votre débit de sauvegarde est inférieur à votre taux de changement, et vous essayez de tout caser dans une fenêtre qui ne suffit pas.

Vérifier : latence I/O, charge du nœud, tendance de la durée des sauvegardes, et si les jobs se chevauchent. Ensuite corrigez l’ordonnancement, la concurrence ou le stockage — pas seulement le message du log.

10) Pannes dans la pipeline VMA/compression (broken pipe, espace tmp, pression des threads zstd)

vzdump pipe les données à travers des outils (vma, compression, possiblement chiffrement selon la cible). Si la pipeline casse — écriture cible bloquée, processus tué par OOM, tmp plein — vous verrez « broken pipe », « killed » ou des codes de sortie génériques.

Vérifier : journal systemd pour OOM kills, RAM libre, activité swap, et le log de sauvegarde autour du démarrage de la compression.

Blague #1 : Les sauvegardes sont comme des parachutes — si vous en avez besoin et qu’il ne s’ouvre pas, vous aurez un postmortem très court.

Tâches pratiques : commandes, signification des sorties et décisions

Ces étapes sont volontairement pratiques. Exécutez-les dans l’ordre jusqu’à trouver la « première erreur réelle ». Les extraits de sortie sont représentatifs ; vos chaînes exactes varieront. L’important est la décision suivante.

Tâche 1 : Identifier rapidement le job en échec et la VM/CT

cr0x@server:~$ grep -R "TASK ERROR" -n /var/log/vzdump/ | tail -n 5
/var/log/vzdump/qemu-101.log:68:TASK ERROR: job errors
/var/log/vzdump/lxc-203.log:55:TASK ERROR: job errors

Ce que ça signifie : Vous avez des logs par invité. Ne vous fiez pas au résumé du GUI ; ouvrez le log spécifique pour l’invité qui a échoué.

Décision : Prenez le log d’échec le plus récent et travaillez dessus jusqu’à la vérité terrain avant de courir après des défaillances secondaires.

Tâche 2 : Extraire la première ligne ERROR et les 30 lignes avant

cr0x@server:~$ awk 'BEGIN{e=0} /ERROR:/{e=NR} {a[NR]=$0} END{for(i=e-30;i<=e+5;i++) if(i>0) print a[i]}' /var/log/vzdump/qemu-101.log
INFO: starting new backup job: vzdump 101 --storage backup --mode snapshot --compress zstd
INFO: filesystem type on dumpdir is 'nfs'
INFO: creating vzdump archive '/mnt/pve/backup/dump/vzdump-qemu-101-2025_12_26-02_00_01.vma.zst'
ERROR: vzdump archive creation failed: write error: No space left on device
INFO: Backup job finished with errors

Ce que ça signifie : La première erreur significative est souvent la seule qui compte.

Décision : Si elle concerne l’écriture cible, arrêtez-vous et corrigez la capacité/mount/permissions du stockage avant de toucher aux paramètres de snapshot.

Tâche 3 : Vérifier que Proxmox considère le stockage de sauvegarde comme actif

cr0x@server:~$ pvesm status --storage backup
Name    Type  Status  Total        Used        Available   %
backup  nfs   active  2048000000   2039000000  9000000     99.56%

Ce que ça signifie : « active » n’indique que « monté » et « répond maintenant ». Ça ne veut pas dire « a de l’espace » ou « est suffisamment rapide ».

Décision : Si l’espace disponible est minime, purgez d’anciennes sauvegardes ou étendez. Si les totaux semblent faux (par exemple 0), suspectez un problème de montage.

Tâche 4 : Confirmer que le point de montage est réel (et pas un répertoire local)

cr0x@server:~$ findmnt -T /mnt/pve/backup
TARGET         SOURCE               FSTYPE OPTIONS
/mnt/pve/backup 10.10.0.20:/exports/pve-backup nfs4   rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2

Ce que ça signifie : Si SOURCE est vide ou ressemble à un device local, vous n’êtes pas monté là où vous pensez.

Décision : Si ce n’est pas monté, n’exécutez pas d’autres sauvegardes. Réparez le montage et nettoyez les « sauvegardes locales accidentelles » qui ont rempli votre nœud.

Tâche 5 : Mesurer l’espace libre réel où vzdump écrit

cr0x@server:~$ df -h /mnt/pve/backup
Filesystem                      Size  Used Avail Use% Mounted on
10.10.0.20:/exports/pve-backup  2.0T  2.0T  9.0G 100% /mnt/pve/backup

Ce que ça signifie : Le diagnostic est fait. C’est plein.

Décision : Purgez des sauvegardes, déplacez-en quelques-unes ou étendez. Puis relancez une sauvegarde manuelle pour prouver la correction.

Tâche 6 : Vérifier les surprises de quota/réservation (commun sur des serveurs NFS basés ZFS)

cr0x@server:~$ zfs get -o name,property,value,source quota,reservation,refquota,refreservation tank/pve-backup
NAME            PROPERTY         VALUE  SOURCE
tank/pve-backup quota            2T     local
tank/pve-backup reservation      none   default
tank/pve-backup refquota         none   default
tank/pve-backup refreservation   none   default

Ce que ça signifie : Un quota de dataset peut rendre un filesystem « plein » alors que le pool a de l’espace libre.

Décision : Si le quota du dataset est serré, augmentez-le ou implémentez une politique de purge qui respecte la rétention.

Tâche 7 : Détecter les erreurs de transport NFS dans les logs du kernel

cr0x@server:~$ dmesg -T | egrep -i "nfs|stale|server not responding|timed out|rpc" | tail -n 20
[Thu Dec 26 02:05:11 2025] NFS: server 10.10.0.20 not responding, still trying
[Thu Dec 26 02:05:44 2025] NFS: server 10.10.0.20 OK

Ce que ça signifie : Votre « problème de stockage » peut être en fait une perte de paquets, de la congestion ou un NAS très occupé.

Décision : Si vous voyez cela pendant la fenêtre de sauvegarde, traitez le réseau et la performance du serveur NFS comme des dépendances de première classe pour les sauvegardes.

Tâche 8 : Repérer des jobs vzdump bloqués ou qui se chevauchent

cr0x@server:~$ pgrep -a vzdump
21984 /usr/bin/perl /usr/bin/vzdump 101 --storage backup --mode snapshot --compress zstd

cr0x@server:~$ pvesh get /nodes/$(hostname)/tasks --limit 5
┌──────────────┬───────────────────────────────┬───────────┬──────────┬─────────┬──────────────┐
│ upid         │ starttime                     │ type      │ status   │ user    │ id           │
╞══════════════╪═══════════════════════════════╪═══════════╪══════════╪═════════╪══════════════╡
│ UPID:node... │ 2025-12-26T02:00:01Z          │ vzdump    │ running  │ root@pam│ 101          │
└──────────────┴───────────────────────────────┴───────────┴──────────┴─────────┴──────────────┘

Ce que ça signifie : Le job est toujours en cours ; un e‑mail d’échec peut provenir d’un autre invité ou d’une tentative antérieure.

Décision : S’il est vraiment bloqué (aucun progrès, stockage gelé), vous devrez peut‑être arrêter la tâche et nettoyer les verrous avec précaution.

Tâche 9 : Vérifier la présence de verrous de sauvegarde sur l’invité

cr0x@server:~$ qm config 101 | egrep -i "lock|backup"
lock: backup

Ce que ça signifie : Proxmox pense qu’une sauvegarde est en cours (ou a été interrompue).

Décision : Confirmez qu’aucun processus vzdump n’est réellement actif. Sinon, supprimez le verrou.

cr0x@server:~$ qm unlock 101
OK

Tâche 10 : Vérifier la capacité de snapshot et le type de stockage des disques de la VM

cr0x@server:~$ qm config 101 | egrep -i "scsi|virtio|ide|sata"
scsi0: local-lvm:vm-101-disk-0,size=80G

cr0x@server:~$ pvesm status --storage local-lvm
Name      Type    Status  Total       Used       Available  %
local-lvm lvmthin active  500000000   310000000  190000000  62.00%

Ce que ça signifie : LVM-thin supporte les snapshots, mais seulement si la metadata thin est saine.

Décision : Si vous êtes sur dir (pas LVM-thin/ZFS/Ceph) et que vous exigez le mode snapshot, attendez-vous à des déceptions.

Tâche 11 : Vérifier l’usage de la metadata LVM-thin (le tueur silencieux des snapshots)

cr0x@server:~$ lvs -a -o+seg_monitor,metadata_percent,lv_size,data_percent vg0
  LV                VG   Attr       LSize   Pool     Data%  Meta%  Monitor
  data              vg0  twi-aotz--  465.76g          68.12  98.77  monitored

Ce que ça signifie : Meta% à ~99% est une alerte rouge. Les snapshots et allocations peuvent échouer abruptement.

Décision : Étendez le LV de metadata thin (si prévu) ou réduisez le churn. N’attendez pas qu’il se libère ; ça n’arrivera pas seul.

Tâche 12 : Vérifier la santé du pool ZFS si les disques VM résident sur ZFS

cr0x@server:~$ zpool status -x
all pools are healthy

cr0x@server:~$ zpool status
  pool: rpool
 state: DEGRADED
status: One or more devices has experienced an error resulting in data corruption.
  scan: scrub repaired 0B in 00:12:44 with 2 errors on Thu Dec 26 01:10:02 2025
config:
        NAME        STATE     READ WRITE CKSUM
        rpool       DEGRADED     0     0     0
          mirror-0  DEGRADED     0     0     0
            nvme0n1 ONLINE       0     0     0
            nvme1n1 ONLINE       0     0     2

Ce que ça signifie : Les erreurs de checksum détectées pendant un scrub ne sont pas « juste un avertissement ». Les sauvegardes qui lisent tout risquent de buter sur la même corruption.

Décision : Remplacez/fixez le device défaillant, restaurez les données affectées à partir de copies saines, puis ne faites confiance aux sauvegardes qu’après validation.

Tâche 13 : Vérifier la santé Ceph si vous utilisez RBD

cr0x@server:~$ ceph -s
  cluster:
    id:     2c1b2d24-aaaa-bbbb-cccc-6f4f3b2d1b2a
    health: HEALTH_WARN
            Degraded data redundancy: 12/3456 objects degraded
  services:
    mon: 3 daemons, quorum mon1,mon2,mon3
    osd: 6 osds: 6 up, 6 in
  data:
    pools:   3 pools, 256 pgs
    objects: 1.15M objects, 4.2 TiB
    usage:   12 TiB used, 18 TiB / 30 TiB avail
    pgs:     10 degraded, 5 undersized

Ce que ça signifie : PGs dégradés/undersized peuvent ralentir ou faire échouer les snapshots, et les lectures peuvent se bloquer.

Décision : Réparez la santé Ceph d’abord. « Sauvegarder plus fort » n’est pas une stratégie de réparation de stockage.

Tâche 14 : Confirmer le statut de l’agent invité (pour freeze/thaw et consistance)

cr0x@server:~$ qm agent 101 ping
QEMU guest agent is running

cr0x@server:~$ qm agent 101 fsfreeze-status
thawed

Ce que ça signifie : L’agent est joignable et peut rapporter l’état de gel des systèmes de fichiers.

Décision : Si les commandes agent échouent, corrigez l’agent dans la VM ou ajustez vos attentes (sauvegarde crash-consistent). Ne prétendez pas obtenir des snapshots application-consistents si ce n’est pas le cas.

Tâche 15 : Détecter les OOM kills ou processus de compression tués

cr0x@server:~$ journalctl -k --since "2025-12-26 01:50" | egrep -i "oom|killed process" | tail -n 20
Dec 26 02:03:22 node kernel: Out of memory: Killed process 22311 (zstd) total-vm:8123456kB, anon-rss:2147488kB, file-rss:0kB, shmem-rss:0kB

Ce que ça signifie : La pipeline de sauvegarde est morte parce que le kernel avait besoin de mémoire plus que votre sauvegarde.

Décision : Réduisez le niveau/threads de compression, étalez les jobs, ajoutez de la RAM, ou externalisez la compression (PBS peut aider). Sinon vous continuerez à « échouer avec succès » chaque nuit.

Tâche 16 : Tester le débit d’écriture vers le stockage cible (ne pas benchmarker indéfiniment)

cr0x@server:~$ dd if=/dev/zero of=/mnt/pve/backup/.pve-write-test bs=16M count=128 oflag=direct status=progress
2147483648 bytes (2.1 GB, 2.0 GiB) copied, 18 s, 119 MB/s
128+0 records in
128+0 records out
2147483648 bytes (2.1 GB, 2.0 GiB) copied, 18.0832 s, 119 MB/s

cr0x@server:~$ rm -f /mnt/pve/backup/.pve-write-test

Ce que ça signifie : Si vous voyez des débits à un chiffre MB/s sur un système qui faisait 200 MB/s auparavant, votre « backup failed » est une régression de performance.

Décision : Réparez le réseau, le NAS, ou la contention. Ou ajustez la concurrence des sauvegardes pour que votre fenêtre soit réaliste.

Tâche 17 : Lancer une sauvegarde manuelle d’un invité avec verbosité maximale et concurrence minimale

cr0x@server:~$ vzdump 101 --storage backup --mode snapshot --compress zstd --notes-template '{{guestname}} {{vmid}}' --stdout 0
INFO: starting new backup job: vzdump 101 --storage backup --mode snapshot --compress zstd --notes-template {{guestname}} {{vmid}} --stdout 0
INFO: issuing guest-agent 'fsfreeze-freeze'
INFO: creating snapshot 'vzdump'
INFO: starting kvm to execute backup task
INFO: creating vzdump archive '/mnt/pve/backup/dump/vzdump-qemu-101-2025_12_26-03_10_01.vma.zst'
INFO: issuing guest-agent 'fsfreeze-thaw'
INFO: archive file size: 14.32GB
INFO: Finished Backup of VM 101 (00:05:54)
INFO: Backup job finished successfully

Ce que ça signifie : Un run contrôlé unique vous dit si le problème est systémique ou dû à la concurrence/l’ordonnancement.

Décision : Si le manuel fonctionne mais que le job nocturne échoue, corrigez l’ordonnancement, la contention du stockage, ou les paramètres des jobs — pas la VM.

Blague #2 : La seule chose plus fiable qu’un job de sauvegarde qui échoue est l’objet de mail qui dit qu’il a échoué « avec succès ».

Trois mini-récits du monde de l’entreprise (anonymisés, plausibles et douloureux)

Mini-récit 1 : La mauvaise hypothèse (NFS est « juste un disque »)

Ils avaient un petit cluster Proxmox pour des apps internes : runners CI, quelques bases de données, et une flopée de VMs « temporaires » restées temporaires depuis trois ans. Les sauvegardes allaient sur un partage NFS sur une appliance NAS. Rien d’exotique. Ça marchait bien jusqu’à ce que ça ne marche plus.

L’hypothèse était simple : « si le stockage montre actif, c’est monté, donc les sauvegardes arrivent sur le NAS. » Presque vrai. L’erreur était que le partage NFS échouait parfois à se monter au boot à cause d’un problème d’ordre de dépendances, laissant /mnt/pve/backup comme répertoire local vide. Le job de sauvegarde s’exécutait, écrivait localement, puis échouait quand le stockage local était plein. Certaines nuits ça « marchait » (écrivait localement sans remplir), d’autres nuits ça échouait. Le NAS paraît innocent tout du long.

L’ingénieur on-call a pisté le NAS pendant une semaine : firmware, disques, charge, réseau. Pendant ce temps, le stockage local d’un nœud se remplissait silencieusement de fichiers partiels .vma.zst. L’indice réel était dans les logs : « filesystem type on dumpdir is ‘ext4’ » les mauvaises nuits et « nfs » les bonnes nuits. Le log disait la vérité ; personne n’écoutait.

La solution n’était pas géniale : assurer l’ordre de montage (dépendances systemd), ajouter une surveillance qui alerte si le stockage de sauvegarde n’est pas le type de filesystem attendu, et faire échouer vite le job de sauvegarde si le montage n’est pas présent. Ils ont aussi nettoyé les « sauvegardes fantômes » locales et ajouté une rétention qui empêchait le NAS d’atteindre 99% à nouveau.

La leçon : traitez le stockage réseau comme une dépendance réseau, pas comme un répertoire qui marche aujourd’hui.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux (la compression devenue déni de service)

Une autre organisation a voulu réduire les coûts de stockage. Quelqu’un a activé la compression zstd à un niveau plus élevé et a autorisé plusieurs jobs vzdump concurrents. En test, tout allait bien : la sauvegarde d’une VM devenait plus petite sans prendre beaucoup plus de temps. Tout le monde est rentré chez lui content.

En production, le nœud avait un mélange de charges. Pendant la fenêtre de sauvegarde, la CPU a explosé, l’IO wait a augmenté, et les services sensibles à la latence ont commencé à timeout. Les sauvegardes ont commencé à échouer avec « broken pipe » et parfois « killed process ». Les pires nuits, l’OOM killer du kernel a tué le processus de compression. Les secondes pires nuits, il a tué quelque chose de plus intéressant.

L’optimisation reposait sur un mauvais modèle mental : « la compression économise l’I/O, donc c’est toujours moins coûteux pour le système. » La compression réduit les octets sur le réseau et le disque, mais elle coûte du CPU et du bandwidth mémoire. Si votre cible est lente, vous pouvez être gagnant. Si votre cible est rapide et le nœud déjà occupé, la compression ajoute juste de la chaleur.

La correction a été de réduire la concurrence, revenir à un niveau de compression raisonnable, et planifier les gros invités séparément. Ils ont aussi déplacé plus de sauvegardes vers PBS où le chunking et la déduplication ont changé l’équation, et le nœud a arrêté de faire autant de travail cher pendant les pics.

La leçon : le réglage « optimal » est celui qui se termine de manière fiable sans nuire à la production. Des archives plus petites sont mignonnes ; des restaurations stables conservent votre emploi.

Mini-récit 3 : La pratique ennuyeuse qui a sauvé la mise (scrubs, contrôles SMART et tests de restauration)

Cette équipe utilisait Proxmox avec ZFS. Rien de spécial : SSDs en miroir pour l’OS, un pool plus grand pour le stockage VM. Ils étaient ennuyeux dans le bon sens : scrubs hebdomadaires, contrôles SMART, et un exercice de restauration mensuel dans un réseau isolé. L’exercice de restauration était détesté par tous. Il prenait du temps. Il provoquait des tickets. Il demandait de l’attention. C’était aussi la raison pour laquelle ils n’avaient pas d’incident avec le mot « regret » dedans.

Un vendredi, des sauvegardes ont commencé à échouer pour une VM spécifique avec une erreur de lecture générique. L’application tournait encore. Les utilisateurs étaient contents. L’on-call aurait pu hausser les épaules et désactiver les alertes jusqu’au lundi. Au lieu de ça, ils ont vérifié zpool status et ont vu des erreurs de checksum. Un scrub a confirmé quelques mauvais blocs sur un SSD. Pas de voyants rouges, pas de panne dramatique — juste des signes précoces.

Ils ont remplacé le device pendant une fenêtre planifiée. Puis ils ont lancé l’exercice de restauration plus tôt que prévu : restaurer la sauvegarde de la nuit précédente dans le sandbox, booter et valider la santé applicative basique. Ça a marché. Ça a confirmé la chaîne de sauvegarde et la procédure de récupération, pas seulement l’existence de fichiers d’archive.

La pratique ennuyeuse a payé deux fois : d’abord en détectant la dégradation avant qu’elle ne devienne perte de données, ensuite en prouvant que les sauvegardes étaient réellement restaurables. Pas théoriquement restaurables. Pas « ça devrait être ok ». Restaurables.

Une idée paraphrasée : Werner Vogels (CTO d’Amazon) a souligné qu’il faut « concevoir pour la défaillance » plutôt que de supposer que les composants ne tomberont pas en panne. (idée paraphrasée)

Erreurs courantes : symptômes → cause racine → correction

1) « Stockage de sauvegarde actif » mais les sauvegardes remplissent le disque local

Symptômes : l’utilisation du disque local augmente ; le stockage de sauvegarde semble correct ; les logs vzdump mentionnent ext4 au lieu de nfs ; des archives apparaissent sous /mnt/pve/backup mais ce chemin est local.

Cause racine : la cible de sauvegarde n’était pas montée, ou le montage a échoué de façon transitoire ; le répertoire existait localement.

Correction : imposer les dépendances de montage, alerter sur un mismatch de type de filesystem via findmnt, et faire échouer tôt la sauvegarde si le montage est absent. Nettoyer les fichiers locaux accidentels.

2) Le mode snapshot échoue seulement pour certains invités

Symptômes : « snapshot failed » ou « unable to create snapshot » pour une VM ; les autres réussissent.

Cause racine : cet invité a un disque sur un stockage qui ne supporte pas les snapshots (par ex. directory), ou a une config non supportée (par ex. raw device mapping bizarre), ou la metadata thin est épuisée au moment de la création du snapshot.

Correction : déplacer les disques vers un stockage supportant les snapshots ; corriger la pression sur la metadata LVM-thin ; vérifier la config via qm config et le type de stockage.

3) « stale file handle » sur NFS pendant la sauvegarde

Symptômes : vzdump échoue en cours d’écriture ; les logs kernel montrent stale handle ; parfois ça se résout au remount.

Cause racine : l’export a changé, le serveur a été rebooté, le filesystem sous-jacent a été re-exporté, ou une maintenance agressive côté NAS. Parfois déclenché par un snapshot du filesystem exporté sur le NAS.

Correction : stabiliser les exports ; éviter de changer les racines d’export ; utiliser des montages hard ; coordonner les snapshots/maintenances NAS en dehors de la fenêtre de sauvegarde ; remonter et retenter.

4) « Permission denied » alors que le partage est inscriptible depuis le shell

Symptômes : vous pouvez faire touch manuellement, mais vzdump échoue lors de la création d’une archive.

Cause racine : root-squash sur NFS, mauvais propriétaire sous le répertoire cible, ou le job de sauvegarde écrit dans un sous-répertoire avec des permissions différentes.

Correction : vérifier les options d’export côté serveur ; définir la bonne propriété/permissions sur le répertoire de dump ; utiliser un mapping UID/GID cohérent.

5) Code de sortie 1 avec « broken pipe »

Symptômes : le log mentionne « broken pipe » pendant la compression ou la création d’archive.

Cause racine : l’écrivain en aval est mort : stockage cible gelé/déconnecté, espace plein, ou processus tué (OOM).

Correction : vérifier OOM kills ; vérifier les logs du stockage cible et l’espace libre ; réduire la compression ou la concurrence ; corriger le transport instable.

6) Les sauvegardes réussissent mais les restaurations sont lentes ou échouent à la vérification

Symptômes : sauvegardes terminées, mais les restaurations prennent une éternité ou échouent aux vérifications (fréquent avec PBS si le datastore est dégradé).

Cause racine : dégradation du stockage sous-jacent, problèmes du chunk store, ou corruption silencieuse détectée ultérieurement.

Correction : vérifier régulièrement la santé du datastore ; lancer des scrubs/contrôles SMART ; effectuer des restaurations de test périodiques.

7) Les sauvegardes passent en timeout seulement pendant les heures de bureau

Symptômes : les jobs se bloquent/stagnent ; NFS « server not responding » ; pics de latence Ceph ; hausse de IO wait.

Cause racine : contention. Les sauvegardes se battent avec la charge de production sur le même stockage/réseau.

Correction : déplacer les sauvegardes en heures creuses, limiter la concurrence, isoler le trafic de sauvegarde, ou améliorer le goulot (souvent réseau ou CPU du NAS).

Checklists / plan étape par étape

Étape par étape : faire réussir la sauvegarde de ce soir

1. Ouvrir le log spécifique : /var/log/vzdump/qemu-<vmid>.log ou lxc-<ctid>.log. Trouver la première ERROR: significative.
2. Confirmer le stockage cible : pvesm status et df -h /mnt/pve/<storage>.
3. Valider la réalité du montage : findmnt -T /mnt/pve/<storage>. Si ce n’est pas le fstype/source attendu, arrêter et corriger d’abord.
4. Libérer de l’espace rapidement si besoin : supprimer ou déplacer d’anciennes sauvegardes selon votre politique de rétention. Ne faites pas de rm -rf à l’aveugle si vous tenez à votre poste.
5. Vérifier les verrous : qm config <vmid> pour lock: backup ; retirer avec qm unlock seulement après avoir confirmé qu’aucun job n’est en cours.
6. Si erreurs de snapshot : vérifier la metadata LVM-thin (lvs ... metadata_percent) ou la santé ZFS/Ceph.
7. Lancer une sauvegarde manuelle : vzdump <vmid> --storage ... --mode snapshot pour prouver la correction. Ne comptez pas sur le job programmé « qui peut‑être » fonctionnera.
8. Documenter la cause : une ligne : « Sauvegarde échouée parce que X ; vérifié par Y ; corrigé par Z ; validé par sauvegarde manuelle. » Votre futur vous offrira un café.

Étape par étape : prévenir les répétitions (réduire la probabilité d’échec)

1. Marge de capacité : gardez les cibles de sauvegarde sous ~80–85% d’utilisation. Au‑delà, tout devient fragile : fragmentation, pression GC, surprises de quota.
2. Rendre les échecs de montage bruyants : surveillez la sortie de findmnt et alertez si la source/fstype du stockage de sauvegarde change.
3. Contrôler la concurrence : moins de sauvegardes parallèles signifie souvent plus de succès total. Tenez compte du taux de complétion, pas du débit théorique.
4. Séparer les gros invités : planifiez les grosses DB ou serveurs de fichiers dans leur propre fenêtre. Ils dominent l’I/O et font accuser les autres.
5. Routines de santé du stockage : cadence de scrub ZFS ; monitoring SMART ; gate sur la santé Ceph. Les sauvegardes ne doivent pas être votre premier signal de défaillance disque.
6. Tests de restauration périodiques : prouvez que vous pouvez restaurer et booter, pas seulement écrire des archives.

Feuille de route opératoire (à imprimer)

1. Le log indique espace/permission/I/O ? Corrigez cette chose précise d’abord.
2. Vérifiez que le montage est réel et stable (NFS/CIFS/PBS).
3. Vérifiez la couche snapshot (LVM-thin meta%, ZFS pool, Ceph health).
4. Vérifiez les verrous et jobs bloqués.
5. Vérifiez la régression de performance (test dd + dmesg + iostat si utilisé).
6. Relancez une sauvegarde manuelle pour confirmer.

FAQ

1) Où se trouvent les vrais logs vzdump sur Proxmox ?

Regardez dans /var/log/vzdump/. Il y a typiquement un log par invité et par exécution (par ex. qemu-101.log, lxc-203.log). La vue des tâches dans le GUI est un résumé, pas toute l’histoire.

2) Pourquoi vzdump dit « backup failed » alors que le fichier d’archive existe ?

Parce que créer un fichier n’est pas la définition du succès. Le job peut échouer après l’écriture (étape de vérification, finalisation, flush, permissions sur les fichiers temporaires, ou hooks post-backup). Vérifiez la fin du log pour l’erreur finale et si la taille de l’archive semble cohérente.

3) Dois‑je utiliser le mode snapshot ou le mode stop ?

Le mode snapshot est le défaut pour une raison : il évite les interruptions. Utilisez stop mode pour des invités qui ne peuvent pas être snapshotés en toute sécurité (rare) ou quand le stockage ne peut pas snapshotter de façon fiable et que vous préférez une sauvegarde propre plutôt que la disponibilité.

4) Que signifie « lock: backup » et est‑il sûr de débloquer ?

Cela signifie que Proxmox pense qu’une sauvegarde est en cours ou a été interrompue. Déverrouiller n’est sûr qu’après avoir confirmé qu’aucune tâche vzdump n’est en cours pour cet invité et qu’aucune opération de snapshot de stockage n’est encore active. Sinon, vous risquez un état incohérent.

5) Comment savoir si c’est NFS le problème versus le disque local ?

Deux indicateurs rapides : findmnt -T /mnt/pve/backup (est‑il monté depuis le serveur attendu ?) et dmesg -T pour les erreurs NFS pendant la fenêtre de sauvegarde. Si le type de filesystem est erroné dans le log vzdump, ce n’est pas NFS — vous écriviez localement.

6) Pourquoi les sauvegardes révèlent-elles la corruption du stockage avant que les utilisateurs ne s’en rendent compte ?

Les sauvegardes lisent largement et séquentiellement sur les disques VM. Les charges régulières peuvent ne toucher que des régions « chaudes » et ne jamais rencontrer un mauvais bloc pendant des mois. La sauvegarde est un test d’intégrité accidentel — ne gaspillez pas ce signal.

7) La compression plus élevée est‑elle toujours meilleure pour les sauvegardes ?

Non. Une compression plus forte peut réduire l’utilisation disque et réseau, mais augmente la charge CPU et la pression mémoire, et peut provoquer des chevauchements de jobs. Choisissez un réglage qui se termine de manière fiable dans votre fenêtre.

8) Que faire si les sauvegardes PBS échouent mais que les NFS fonctionnent (ou vice versa) ?

Cela pointe généralement vers la cible : problèmes d’auth/token, datastore plein, contentions verification/GC sur PBS, ou problèmes d’export/permissions NFS. Séparez le système : confirmez le réseau nœud→cible puis vérifiez la santé et les logs côté cible.

9) Comment prouver une correction sans attendre demain ?

Lancez une sauvegarde manuelle pour un invité représentatif immédiatement après le changement. Si le job nocturne échouait à cause de la concurrence, lancez deux backups en parallèle et voyez si l’échec revient. Les preuves valent mieux que l’espoir.

10) Quelle est l’habitude de fiabilité la plus efficace pour les sauvegardes ?

Tester les restaurations régulièrement. Pas une fois. Pas après un incident. Volontairement, de manière routinière. Les sauvegardes ne valent que par votre dernière restauration réussie.

Conclusion : prochaines étapes qui réduisent vraiment le bruit des pagers

Quand Proxmox indique « vzdump backup failed », il n’est pas vague par malice ; il vous dit que la défaillance est survenue dans une chaîne de dépendances. La correction la plus rapide est d’identifier la première erreur concrète dans le log par invité, valider que le stockage cible est réel et inscriptible, puis vérifier la capacité de snapshot et la santé du stockage avant de toucher aux réglages.

Faites ceci ensuite, dans cet ordre :

1. Ajouter une vérification de sanity du montage (type de filesystem et source) avant l’exécution des sauvegardes, et alerter si cela change.
2. Appliquer une marge sur le stockage de sauvegarde (rétention/pruning, quotas maîtrisés et politique stricte « stop à 85% »).
3. Auditer la préparation aux snapshots (pourcentage metadata LVM-thin, santé des pools ZFS, santé Ceph) et bloquer les sauvegardes si la plateforme est dégradée.
4. Redimensionner concurrence et compression pour que les jobs se terminent de façon fiable. Votre fenêtre de sauvegarde est un budget ; ne le dépassez pas.
5. Planifier des drills de restauration et les traiter comme des alarmes incendie : agaçants, nécessaires, et la différence entre un événement contrôlé et un rapport d’incident.