Sauvegardes Proxmox vers PBS échouent : erreurs courantes de chunks/espace et solutions

janvier 15, 2026 • février 3, 2026 • Lecture : 29 min • Views: 9

Cet article vous a aidé ?

Vous avez programmé des sauvegardes, regardé les premières réussir, et rangé mentalement le tout sous « géré ». Puis un test de restauration (ou pire, un incident réel) révèle que les sauvegardes échouent depuis des jours avec des messages concernant des chunks, de l’espace, des verrous ou un « unexpected EOF ». C’est l’équivalent, pour les sauvegardes, de découvrir que votre détecteur de fumée a couiné dans un immeuble vide.

Proxmox Backup Server (PBS) est bien conçu, mais c’est un système de stockage avec ses règles : chunks dédupliqués, index, snapshots, garbage collection et un datastore qui appliquera absolument les lois de la physique. Quand les sauvegardes échouent, vous avez généralement affaire à l’une des quatre réalités : pas d’espace, pas d’inodes, comportement de stockage défaillant ou incohérence métadonnées/index. L’astuce est d’identifier rapidement laquelle, puis d’agir sans aggraver la situation.

À quoi ressemblent réellement les échecs PBS (et pourquoi c’est déroutant)

Les messages d’erreur PBS mentionnent souvent « chunks », « indexes », « catalog », « snapshot », « datastore » ou « verification ». Si vous venez de solutions de type copie de fichiers, cela paraît inutilement abstrait. Dans PBS, le flux de sauvegarde est découpé en chunks (de taille variable), hachés et dédupliqués. Les métadonnées (indexes) relient votre image VM/CT à ces chunks. Données et métadonnées sont toutes deux nécessaires pour une restauration.

Vous pouvez donc obtenir des échecs à au moins cinq niveaux :

Transport/auth : PVE ne peut pas s’authentifier auprès de PBS, ou TLS casse.
Dépôt/datastore : chemin non inscriptible, datastore verrouillé, permissions incorrectes.
Capacité : octets, inodes ou contraintes de « espace réservé » interrompent les écritures en plein flux.
Intégrité du stockage : disque sous-jacent renvoie des erreurs I/O, ou le système de fichiers commence à mentir.
Incohérence index/chunk : chunk manquant, index corrompu, échecs de vérification.

Votre travail en tant qu’adulte de permanence est d’identifier la contrainte la plus serrée en premier. Ne courez pas après le message ; traquez le goulot qui rend le message inévitable.

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

Si vous avez dix minutes avant la prochaine réunion en colère, faites ceci dans l’ordre. C’est optimisé pour « ce qui casse le plus souvent » et « ce que vous pouvez confirmer le plus vite », pas pour l’élégance.

1) Vérification rapide de la réalité de la capacité : octets, inodes et santé du pool

Sur PBS : vérifiez l’espace libre (df -h) et les inodes (df -i) sur le point de montage du datastore.
Si ZFS : vérifiez zpool list, zpool status et l’utilisation des datasets (zfs list).
Cherchez des conditions « 80–90% plein ». Sur les systèmes CoW, c’est là que performance et fragmentation deviennent punitives.

2) Identifiez rapidement le job en échec et la classe d’erreur

Sur PVE : lisez le journal du job dans l’UI, mais confirmez avec journalctl pour le contexte et les horodatages.
Sur PBS : lisez journalctl -u proxmox-backup. La même défaillance peut montrer des causes plus claires côté serveur.
Décidez : est-ce de l’espace, permissions/verrou, I/O, ou intégrité chunk/index ?

3) Cessez d’aggraver la situation : mettez les jobs en pause, protégez ce qui est bon

Si le datastore est presque plein : arrêtez les jobs de sauvegarde, lancez prune/GC de façon délibérée, et n’exécutez pas une « vérification de tout » maintenant.
Si le pool est dégradé ou rapporte des erreurs de checksum : arrêtez les écritures, réparez le matériel, puis vérifiez.
Si c’est un imbroglio de verrous/permissions : supprimez les verrous obsolètes avec précaution (pas en supprimant des fichiers au hasard), puis relancez un seul job.

Une vérité opérationnelle : quand vous êtes à court d’espace, tout ressemble à de la corruption. Quand vous êtes corrompu, tout ressemble à un problème d’espace. Votre tâche est de séparer les deux.

Faits intéressants et contexte (ce qui explique les bizarreries)

Les sauvegardes dédupliquées ne sont pas des « fichiers plus petits ». PBS stocke les données comme des chunks référencés par des indexes. L’utilisation d’espace dépend de la réutilisation des chunks, pas de la taille des fichiers.
Le chunking est défini par le contenu. Comme les systèmes de dédup classiques, PBS découpe les données selon des rolling hashes, ce qui aide la dédup même lorsque les blocs bougent.
La « vérification » est une fonctionnalité de première classe. Beaucoup de piles de sauvegarde considèrent les contrôles d’intégrité comme optionnels et les exécutent rarement. PBS attend que vous vérifiiez.
La garbage collection est distincte du prune. Prune supprime les références aux snapshots ; GC récupère les chunks non référencés. Les gens oublient la seconde étape.
Les systèmes CoW détestent atteindre 95% d’utilisation. ZFS et btrfs ont besoin d’espace pour les métadonnées et les allocations ; « df indique 5% de libre » n’est pas rassurant.
L’épuisement des inodes existe toujours. Vous pouvez avoir des téraoctets libres et pourtant voir des écritures échouer si le système de fichiers n’a plus d’inodes (surtout avec beaucoup de petits fichiers de chunks).
Les sauvegardes sollicitent des chemins I/O différents de la production. Des lectures séquentielles des disques VM plus des écritures aléatoires vers le datastore peuvent mettre à nu des bugs du contrôleur/firmware que les charges normales ne montrent pas.
La corruption silencieuse est un design assumé. Les systèmes de sauvegarde modernes partent du principe que la bitrot arrive ; les checksums et la vérification existent parce que les disques mentent parfois.
La plupart des problèmes « PBS est lent » sont des problèmes de disposition du stockage. Mauvais ashift, recordsize trop petit, ou un disque unique prétendant être un array feront ressembler PBS au coupable.

Tâches pratiques : commandes, sorties, décisions

Ce sont des tâches réelles que vous pouvez exécuter aujourd’hui. Chaque élément inclut : une commande, ce que la sortie typique signifie, et la décision à prendre.
Exécutez les commandes sur l’hôte approprié (PVE vs PBS). N’utilisez pas d’options destructrices au hasard tant que vous n’avez pas identifié la classe de défaillance.

Task 1: Confirm datastore mount path and free space (PBS)

cr0x@pbs:~$ df -hT
Filesystem     Type   Size  Used Avail Use% Mounted on
/dev/sda2      ext4   917G  812G   59G  94% /
tmpfs          tmpfs   32G     0   32G   0% /dev/shm

Signification : 94% utilisé est une zone dangereuse pour les écritures de sauvegarde et la maintenance du système de fichiers.
Décision : arrêter ou étaler les jobs, lancer prune/GC et libérer de l’espace avant de relancer de grosses sauvegardes.

Task 2: Check inode usage (PBS)

cr0x@pbs:~$ df -i
Filesystem      Inodes   IUsed   IFree IUse% Mounted on
/dev/sda2     61054976 60980012  74964  100% /

Signification : Vous êtes à court d’inodes. Les écritures échouent même si des octets sont disponibles.
Décision : prune des anciens snapshots, lancer GC, et envisager de migrer le datastore vers un système de fichiers/dataset dimensionné pour de nombreux fichiers. Revoir aussi la disposition des chunks/index et la rétention.

Task 3: Identify which datastore is configured (PBS)

cr0x@pbs:~$ proxmox-backup-manager datastore list
┌───────────┬───────────────┬────────────┬───────────┐
│ Name      │ Path          │ PruneOpts  │ Comment   │
╞═══════════╪═══════════════╪════════════╪═══════════╡
│ mainstore │ /mnt/datastore│ keep-daily │ primary   │
└───────────┴───────────────┴────────────┴───────────┘

Signification : Vous connaissez maintenant le chemin à vérifier avec df, ls et les outils du système de fichiers.
Décision : concentrez le diagnostic sur le point de montage correct, plutôt que de deviner « / est plein ».

Task 4: Check ZFS pool health (PBS, if applicable)

cr0x@pbs:~$ zpool status
  pool: tank
 state: DEGRADED
status: One or more devices has experienced an error resulting in data corruption.
action: Restore the file in question if possible. Otherwise restore the entire pool from backup.
  scan: scrub repaired 0B in 02:11:45 with 3 errors on Thu Dec 19 03:12:10 2025
config:

        NAME        STATE     READ WRITE CKSUM
        tank        DEGRADED     0     0     0
          raidz1-0  DEGRADED     0     0     0
            sdb     ONLINE       0     0     2
            sdc     ONLINE       0     0     1
            sdd     ONLINE       0     0     0

errors: Permanent errors have been detected in the following files:
        tank/pbs@somefile

Signification : des erreurs de checksum existent. Ce n’est pas un « bug PBS » ; c’est un événement d’intégrité du stockage.
Décision : mettre en pause les écritures intensives, réparer le matériel, lancer un scrub à nouveau, puis exécuter la vérification PBS et planifier des restaurations pour les snapshots affectés.

Task 5: Locate backup failure in PBS logs (PBS)

cr0x@pbs:~$ journalctl -u proxmox-backup --since "today" | tail -n 30
Dec 26 01:12:01 pbs proxmox-backup[2211]: upload failed: No space left on device (os error 28)
Dec 26 01:12:01 pbs proxmox-backup[2211]: failed to finalize backup: unable to write index
Dec 26 01:12:01 pbs proxmox-backup[2211]: job failed: datastore "mainstore" is full

Signification : ENOSPC et échec d’écriture de l’index. Les chunks ont peut-être été écrits mais les métadonnées n’ont pas pu être finalisées.
Décision : libérer de l’espace d’abord, puis relancer. Planifier aussi prune/GC pour éviter une répétition la semaine suivante.

Task 6: Check PVE-side job error context (PVE)

cr0x@pve1:~$ journalctl --since "today" | grep -E "vzdump|proxmox-backup-client" | tail -n 20
Dec 26 01:11:58 pve1 vzdump[18277]: INFO: starting new backup job: vzdump 101 --mode snapshot --storage pbs-main --notes-template '{{guestname}}'
Dec 26 01:12:01 pve1 vzdump[18277]: ERROR: Backup of VM 101 failed - upload failed: No space left on device (os error 28)
Dec 26 01:12:01 pve1 vzdump[18277]: INFO: Failed at 2025-12-26 01:12:01

Signification : Le même ENOSPC remonte. Pas besoin de chercher des fantômes réseau.
Décision : arrêter les nouvelles sauvegardes jusqu’à récupération d’espace sur le datastore.

Task 7: Verify the mount isn’t lying (PBS, common with NFS/iSCSI misadventures)

cr0x@pbs:~$ mount | grep /mnt/datastore
192.0.2.50:/export/pbs on /mnt/datastore type nfs4 (rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2)

Signification : Le datastore est sur NFS. Ça peut fonctionner, mais c’est là que naissent souvent les histoires de « chunks manquants ».
Décision : si vous voyez de la corruption de chunks ou des I/O intermittents, envisagez fortement de déplacer les datastores PBS sur des disques locaux ou une pile de stockage avec checksums de bout en bout.

Task 8: Check for filesystem I/O errors (PBS)

cr0x@pbs:~$ dmesg -T | tail -n 20
[Thu Dec 26 01:10:44 2025] blk_update_request: I/O error, dev sda, sector 194512345 op 0x1:(WRITE) flags 0x0 phys_seg 1 prio class 0
[Thu Dec 26 01:10:44 2025] EXT4-fs error (device sda2): ext4_journal_check_start:83: Detected aborted journal
[Thu Dec 26 01:10:44 2025] EXT4-fs (sda2): Remounting filesystem read-only

Signification : Un disque ou un contrôleur a provoqué le remontage en lecture seule d’ext4. PBS échouera de manière étrange après ce point.
Décision : arrêter les jobs de sauvegarde, réparer le matériel, fsck si nécessaire, puis n’essayer de nouvelles sauvegardes qu’après vérification. Considérez les sauvegardes récentes comme incomplètes jusqu’à preuve du contraire.

Task 9: Check PBS datastore status and usage (PBS)

cr0x@pbs:~$ proxmox-backup-manager datastore status mainstore
┌──────────────┬──────────────────────────────┐
│ Key          │ Value                        │
╞══════════════╪══════════════════════════════╡
│ name         │ mainstore                    │
│ path         │ /mnt/datastore               │
│ total        │ 8.00 TiB                      │
│ used         │ 7.62 TiB                      │
│ avail        │ 0.38 TiB                      │
│ read-only    │ false                        │
└──────────────┴──────────────────────────────┘

Signification : Il ne reste que 0,38 TiB. Cela peut s’évaporer rapidement avec de gros fulls, ou même avec la croissance des métadonnées/index.
Décision : resserrer la rétention, ajouter de la capacité, ou répartir les charges sur plusieurs datastores. Ne comptez pas sur la « dédup » pour tout sauver.

Task 10: Run a targeted verify (PBS)

cr0x@pbs:~$ proxmox-backup-manager verify start mainstore --ns vm --group vm/101
starting verification of datastore 'mainstore'
verifying group 'vm/101'
OK: verified snapshot 'vm/101/2025-12-25T01:10:02Z'
FAILED: snapshot 'vm/101/2025-12-26T01:10:02Z' - missing chunk "3f2c...d91a"
TASK OK: verify datastore mainstore

Signification : Un snapshot est manquant d’un chunk. C’est soit une perte de stockage sous-jacente, soit une écriture interrompue, soit une incohérence index/chunk.
Décision : préservez l’état du datastore (ne « nettoyez » pas au hasard), inspectez la santé du stockage, et planifiez de relancer cette sauvegarde après correction de la capacité/stabilité.

Task 11: Check prune simulation before deleting (PBS)

cr0x@pbs:~$ proxmox-backup-manager prune list mainstore --ns vm --group vm/101 --dry-run
found 14 snapshots
would keep: 7
would remove: 7
  remove vm/101/2025-12-01T01:10:02Z
  remove vm/101/2025-12-02T01:10:02Z
  remove vm/101/2025-12-03T01:10:02Z

Signification : Vous voyez ce que la rétention supprimerait sans engagement.
Décision : si l’espace est critique, procédez au prune, puis lancez GC. Si des contraintes légales existent, arrêtez et ajustez la politique avec les parties prenantes.

Task 12: Run garbage collection (PBS)

cr0x@pbs:~$ proxmox-backup-manager garbage-collection start mainstore
starting garbage collection on datastore 'mainstore'
found 18234 unreferenced chunks
removed 18190 chunks, reclaimed 412.7 GiB
TASK OK: garbage collection

Signification : Espace récupéré. C’est l’étape que les gens oublient après le prune.
Décision : revérifiez l’espace libre ; seulement après redémarrez les plannings de sauvegarde.

Task 13: Inspect datastore file count pressure (PBS)

cr0x@pbs:~$ find /mnt/datastore/.chunks -type f | wc -l
58492312

Signification : Des dizaines de millions de fichiers peuvent mettre à mal les tables d’inodes, les recherches dans les répertoires et même les sauvegardes du serveur de sauvegarde lui-même.
Décision : si vous êtes sur ext4 avec épuisement d’inodes ou douleur de performance, planifiez une migration de datastore (ratio d’inodes plus grand, ou conception ZFS dataset) et reconsidérez la rétention.

Task 14: Confirm repository connectivity and auth (PVE)

cr0x@pve1:~$ proxmox-backup-client login pbs01 --repository backup@pbs@pbs01:mainstore
Password for "backup@pbs@pbs01":
Login succeeded.

Signification : Auth et réseau de base fonctionnent. Si les jobs échouent toujours, c’est probablement une question de capacité ou d’intégrité, pas d’identifiants.
Décision : ne changez pas les mots de passe dans la panique et retournez au diagnostic du datastore.

Task 15: Check for stale lock symptoms (PBS)

cr0x@pbs:~$ journalctl -u proxmox-backup --since "today" | grep -i lock | tail -n 10
Dec 26 00:59:03 pbs proxmox-backup[2144]: unable to acquire lock on snapshot: resource busy
Dec 26 00:59:03 pbs proxmox-backup[2144]: backup failed: datastore is locked by another task

Signification : Une autre tâche (backup, verify, GC, prune) détient le verrou, ou une tâche précédente a planté et laissé un état derrière elle.
Décision : vérifiez les tâches en cours dans l’UI et sur l’hôte ; ne supprimez pas les fichiers de verrouillage à l’aveugle. Si une tâche est bloquée, réparez d’abord le problème I/O sous-jacent.

Task 16: Confirm time sync (PVE and PBS)

cr0x@pbs:~$ timedatectl
               Local time: Fri 2025-12-26 01:20:11 UTC
           Universal time: Fri 2025-12-26 01:20:11 UTC
                 RTC time: Fri 2025-12-26 01:20:11
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Signification : L’heure est synchronisée. Cela compte plus que beaucoup ne l’admettent : certificats expirés, « snapshots futurs » et planifications bizarres peuvent ressembler à des problèmes de stockage.
Décision : si les horloges sont fausses, corrigez NTP d’abord, puis relancez les opérations ayant échoué.

Erreurs de chunks : que signifient-elles et quoi faire

Les erreurs de chunks apparaissent comme « missing chunk », « checksum mismatch », « unable to decode chunk » ou échecs de finalisation d’index.
Traitez-les comme un spectre : des snapshots incomplètes sans gravité (job mort avant commit) à la corruption de stockage réelle.

Chunk manquant

Symptôme typique : la vérification signale des chunks manquants ; la restauration échoue pour un snapshot spécifique.

Causes racines communes :

Écriture de sauvegarde interrompue (ENOSPC en cours, crash serveur, système de fichiers remonté RO).
Incohérence du stockage sous-jacent (hiccups NFS, cache contrôleur RAID mentant, disque instable).
Nettoyage humain (« j’ai supprimé des anciens fichiers chunk pour faire de la place. » S’il vous plaît, ne faites pas ça.)

Que faire :

Confirmer que le système de fichiers du datastore est sain : vérifier dmesg, SMART, RAID, scrubs ZFS.
Vérifier si seul le snapshot le plus récent est affecté. Si oui et que cela coïncide avec ENOSPC ou un crash, relancez la sauvegarde après correction de la capacité.
Si plusieurs snapshots sur la période ont des chunks manquants, supposez que le stockage perd des écritures ou corrompt des données. Arrêtez et corrigez cela d’abord.

Mismatch de checksum / erreurs de décodage

C’est le moment où vous arrêtez de blâmer PBS et commencez à incriminer l’entropie. Les checksums existent parce que les disques renvoient parfois de mauvais bits.

Causes racines : RAM défectueuse (oui, vraiment), un disque renvoyant des données périmées, ou un problème de contrôleur/firmware. Dans un PBS virtualisé, la pile de stockage de l’hyperviseur peut aussi être impliquée.

Que faire : scrub et tester le stockage ; lancer des tests mémoire si la corruption se répète ; vérifier tous les snapshots récents ; et pour les workloads affectés, assurez-vous d’avoir une seconde copie (autre PBS, bande, object store, selon vos règles).

Échecs d’écriture/finalisation d’index

Apparaît souvent comme « unable to write index », « failed to finalize backup », « unexpected EOF ». Le flux de sauvegarde peut uploader beaucoup de chunks, puis échouer à la fin quand l’index/catalog doit être commis. Si l’espace est serré, ce commit final est le point de défaillance.

Que faire : considérez les erreurs d’index comme « sauvegarde invalide tant que non vérifiée ». Corrigez l’espace ou l’état RO du FS, relancez la sauvegarde, puis vérifiez.

Blague #1 : Un chunk manquant, c’est comme une chaussette disparue — agaçant, mystérieux, et ça disparaît toujours quand vous êtes déjà en retard.

Erreurs d’espace : pas seulement « disque plein »

« No space left on device » est brutal. Le problème est que Linux peut le lancer pour au moins quatre types différents d’« espace », et PBS le remontera quand il tente de commettre des données ou des métadonnées. Voici les pièges d’espace qui frappent les opérateurs PBS en production.

1) Épuisement d’octets (disque plein classique)

Simple : df -h indique 100%. Mais le problème plus intéressant est « pas encore 100%, mais effectivement plein ». ZFS, btrfs et même ext4 sous forte fragmentation peuvent mal se comporter bien avant 100%.

Règle : ne pas maintenir un datastore de sauvegarde dédupliqué au-delà de ~80–85% à long terme si vous tenez à la performance et à un GC fiable. Vous pouvez monter plus haut temporairement, mais y vivre continuellement vous coûtera en timeouts et bizarreries.

2) Épuisement d’inodes

Les stockages de chunks PBS peuvent créer un nombre énorme de fichiers. Certains systèmes de fichiers (et certains choix de ratio d’inodes) vous puniront.
Si df -i est élevé, vous pouvez obtenir ENOSPC alors que df -h semble correct.

Correction : prune et GC pour réduire le nombre de chunks, puis planifier une migration de datastore dimensionnée pour de nombreux fichiers. Si vous installez depuis zéro, concevez en tenant compte de la pression sur les inodes.

3) Contraintes d’espace métadonnées/transaction (réalité CoW)

Sur ZFS, vous pouvez avoir de l’« espace libre » mais pas assez d’espace contigu ou de marge pour les métadonnées pour compléter les allocations efficacement. Un pool plein peut rendre le GC extrêmement lent, ce qui signifie que vous ne pouvez pas récupérer l’espace assez vite pour débloquer les sauvegardes. Cela devient une boucle.

Correction : gardez des pools avec marge ; ne considérez pas « ça rentre » comme un succès. Ajoutez des vdevs/capacité avant la falaise. Envisagez des special vdevs uniquement si vous comprenez les domaines de défaillance.

4) « Reserved blocks » et espace réservé root (nuance ext4)

ext4 réserve typiquement un pourcentage de blocs pour root. Si PBS tourne en tant que root (fréquent), il peut tout de même écrire là où d’autres processus ne peuvent pas.
Ou inversement selon l’utilisateur du service et la configuration du point de montage. Cela peut créer des échecs partiels déroutants.

Correction : comprenez vos paramètres de réserve et les permissions du service. Mais ne « supprimez » pas les réserves de sécurité juste pour caser quelques sauvegardes de plus. C’est comme ça qu’on a un système mort à 3h du matin.

Verrous, permissions et « ça marchait hier »

Les systèmes de sauvegarde sont des machines à états avec des bords nets. Les verrous existent pour empêcher les modifications concurrentes du même groupe de snapshots.
Quand les verrous deviennent obsolètes, ou que les permissions changent à la volée, les échecs semblent aléatoires.

Erreurs de permission (chemin datastore, ownership, options de montage)

Symptômes : « permission denied », « read-only filesystem », « failed to create directory », ou jobs qui échouent immédiatement.

Vérification : « Je peux écrire là en root » n’est pas équivalent à « le service PBS peut écrire là dans son contexte d’exécution ». Aussi, un export NFS peut changer silencieusement de comportement après un reboot ou un événement réseau.

Correction : confirmez les options de montage, confirmez les permissions réelles du chemin, et confirmez que le système de fichiers est RW et stable.

Erreurs de verrou

Les verrous sont souvent un symptôme, pas la maladie. Une verify longue, un GC bloqué, ou un système de fichiers I/O-hung peuvent retenir des verrous et provoquer des échecs de sauvegarde.
La bonne démarche n’est pas « supprimer les verrous », mais « pourquoi la tâche est-elle bloquée ».

Une idée paraphrasée de Werner Vogels (CTO Amazon) : « Tout échoue, tout le temps ; concevez des systèmes pour que l’échec soit routinier, pas catastrophique. »

Prune et garbage collection : le train lent

La rétention PBS est une danse en deux étapes :

Prune supprime les références aux snapshots selon la politique.
Garbage collection récupère les chunks qui ne sont plus référencés par aucun snapshot.

Si vous ne faites que prune, votre datastore peut encore sembler plein. Si vous ne faites que GC, rien ne sera récupéré car les snapshots référencent encore les chunks.
Si vous faites les deux alors que le pool est à 95% plein et instable, les deux opérations deviennent lentes et fragiles.

Conseils opérationnels (opinionnés, parce que vous en avez besoin)

Planifiez prune et GC pendant des fenêtres I/O faibles, mais pas si rarement que vous atteignez des plafonds.
Ne superposez pas une verify lourde avec GC sur les petits systèmes. Vos disques passeront la nuit à se chamailler.
Gardez la rétention réaliste. « Tout garder pour toujours » est une commande d’achat de stockage, pas une politique.
Vérifiez les restaurations, pas seulement les sauvegardes. La vérification détecte les chunks manquants ; les tests de restauration détectent les lacunes opérationnelles (clés, permissions, réseau).

Blague #2 : La garbage collection, c’est comme le budget d’entreprise — rien n’est récupéré tant que quelqu’un ne prouve pas que c’est vraiment inutilisé.

Trois mini-récits d’entreprise depuis les tranchées des sauvegardes

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

Une entreprise de taille moyenne a exécuté PBS sur une nouvelle baie de stockage. L’équipe a supposé qu’un « contrôleur RAID avec cache sur batterie » suffisait à sécuriser les écritures.
Ils ont aussi supposé que parce que les VMs de production fonctionnaient bien, les écritures de sauvegarde étaient « moins importantes » et pouvaient tolérer des accros occasionnels.

Le premier signe de problème fut des échecs de verification : des chunks manquants disséminés dans différents groupes de VM. Pas seulement le dernier snapshot.
Les restaurations fonctionnaient parfois, puis échouaient d’autres fois. On a blâmé les mises à jour PBS, ensuite le réseau, puis la « complexité de la dédup ».

Le tournant fut de corréler les horodatages de verify PBS avec les logs du contrôleur montrant des avertissements de destaging du cache et des réinitialisations occasionnelles.
Les écritures de sauvegarde sont à fort débit et en rafales ; elles frappent le contrôleur d’une façon que la charge VM n’expose pas. L’array accusait parfois réception des écritures,
puis les perdait lors d’une fenêtre de reset. PBS a fait son travail : il s’est plaint quand les chunks n’étaient plus là ensuite.

La correction fut ennuyeuse : mise à jour du firmware, remplacement du contrôleur, et déplacement du datastore PBS vers ZFS avec checksums de bout en bout sur un hôte avec RAM ECC.
Les vérifications ont cessé d’échouer. Ils ont aussi ajouté une seconde cible PBS répliquée pour les workloads critiques, car « une copie » n’est pas une stratégie.

Mini-récit 2 : L’optimisation qui a échoué

Un autre site voulait des sauvegardes plus rapides. Ils ont placé le datastore PBS sur un partage NFS soutenu par un NAS rapide. Sur le papier, c’était parfait : beaucoup de capacité,
extension aisée, approbation de l’équipe stockage. Ils ont ajusté rsize/wsize NFS, se sont sentis malins, et ont déclaré victoire.

Pendant un mois, tout semblait OK. Puis apparurent périodiquement des erreurs « unable to decode chunk » et certains snapshots ne pouvaient pas être vérifiés.
Les échecs étaient sporadiques — le classique « c’est toujours le réseau ». L’équipe stockage jurait que le NAS était sain. L’équipe virtualisation jurait que PBS était pointilleux.

La vraie cause était subtile : des blocages NFS intermittents durant les opérations riches en métadonnées et un événement de basculement qui a brièvement changé le comportement de l’export.
Les fichiers de chunks et les indexes sont sensibles aux écritures partielles et au timing. Le NAS était optimisé pour de grandes écritures séquentielles, pas des millions d’objets chunk petits à moyens
avec un churn métadonnées constant.

Ils ont annulé l’« optimisation » et déplacé le datastore sur des miroirs ZFS locaux avec une cible d’espace libre raisonnable. Les sauvegardes ont ralenti légèrement sur le papier,
mais sont devenues constantes et vérifiables. Le meilleur indicateur de performance est « les restaurations fonctionnent », pas « le graphique est joli ».

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une entreprise régulée avait une habitude terne : tests de restauration hebdomadaires d’une VM par cluster, tournant sur une liste.
Pas un feu d’artifice — juste une tâche planifiée avec un ticket, une case à cocher, et une personne qui devait joindre une capture de console et un fichier checksum.

Un week-end, le test de restauration a échoué avec un chunk manquant sur le snapshot le plus récent, mais les snapshots plus anciens se restaurèrent bien.
L’opérateur a escaladé immédiatement, et l’équipe a mis en pause les nouvelles sauvegardes pour éviter d’écraser la situation avec du bruit.

Ils ont découvert que le datastore oscillait autour de 92% d’utilisation et que le GC n’avait pas récupéré d’espace parce que prune s’était exécuté, mais GC était planifié sur une autre fenêtre
et échouait silencieusement à cause de timeouts. Le système n’était pas corrompu ; il étouffait simplement.

Ils ont libéré de l’espace, lancé GC, relancé la sauvegarde échouée, et l’ont vérifiée. Pas de drame. L’important est que le test de restauration l’a détecté
avant qu’un incident réel n’impose une restauration sous pression.

Voilà la leçon : la pratique « ennuyeuse » n’est pas les sauvegardes. C’est prouver que les sauvegardes sont utilisables.

Erreurs courantes : symptômes → cause racine → correctif

1) « No space left on device » pendant la finalisation

Symptômes : l’upload de la sauvegarde transfère la majorité des données puis échoue à la fin ; les logs évoquent la finalisation de l’index.

Cause racine : datastore trop plein ; les métadonnées/index ont besoin d’espace lors du commit.

Fix : prune des snapshots, lancer GC, garder le datastore sous une utilisation raisonnable ; relancer et vérifier.

2) Sauvegardes échouent alors que `df -h` montre de l’espace

Symptômes : ENOSPC mais « 60% libre ».

Cause racine : épuisement d’inodes ou contraintes de quotas/reservations.

Fix : vérifier df -i ; sur ZFS vérifier quotas/reservations de dataset ; réduire le nombre de snapshots via prune ; planifier une migration si la disposition d’inodes est inadaptée.

3) « Missing chunk » sur la vérification pour le snapshot le plus récent seulement

Symptômes : seul le snapshot le plus récent échoue à la vérification ; les anciens sont OK.

Cause racine : sauvegarde interrompue (manque d’espace, crash, FS remonté RO).

Fix : corriger la capacité/santé ; relancer la sauvegarde ; vérifier à nouveau ; envisager d’alerter sur ENOSPC et les remontages RO.

4) « Missing chunk » disséminé sur de nombreux snapshots

Symptômes : échecs de verification sur la durée et entre groupes.

Cause racine : corruption du stockage sous-jacent ou comportement non fiable d’un FS distant.

Fix : arrêter les écritures, lancer diagnostics stockage (scrub, SMART, logs contrôleur), remédier le matériel, puis reverifier et ressemer les sauvegardes.

5) Sauvegardes bloquées ou lentes puis échouent avec timeouts

Symptômes : jobs qui durent des heures ; GC ne finit jamais ; erreurs de verrou occasionnelles.

Cause racine : datastore trop plein (douleur CoW), ou disques saturés par verify/GC/backup concurrents.

Fix : réduire la concurrence ; séparer les fenêtres de verification ; garder de l’espace libre ; déplacer le datastore sur disques plus rapides ou ajouter des vdevs.

6) « Datastore is locked »

Symptômes : nouveaux jobs échouent immédiatement ; les logs mentionnent des verrous.

Cause racine : une autre tâche en cours, ou une tâche bloquée à cause d’un I/O hang.

Fix : identifier les tâches en cours ; résoudre les problèmes I/O ; éviter la suppression manuelle d’état ; relancer un job pour valider.

7) « Read-only filesystem » pendant la sauvegarde

Symptômes : échecs soudains et généralisés ; dmesg montre ext4 remount RO ou faute ZFS.

Cause racine : erreurs I/O matérielles ou réponse de corruption du système de fichiers.

Fix : arrêter, réparer matériel/système de fichiers, puis vérifier la cohérence du datastore et la capacité de restauration.

8) « Authentication failed » après « aucun changement »

Symptômes : jobs échouent au démarrage ; login échoue ; erreurs TLS.

Cause racine : certificats expirés, dérive horaire, rotation de mot de passe non synchronisée, ou faute de frappe dans la chaîne de dépôt.

Fix : vérifier timedatectl ; vérifier le repository ; réauthentifier avec proxmox-backup-client login ; mettre à jour les identifiants dans la config PVE.

Listes de contrôle / plan pas à pas

Checklist A: Quand les sauvegardes commencent à échouer ce soir

Arrêter l’hémorragie : mettre en pause les plannings de sauvegarde si les échecs proviennent d’espace ou d’I/O.
Classer : espace (octets/inodes), intégrité (I/O, checksum), verrous/permissions, ou auth/réseau.
Confirmer la santé du point de montage : df -hT, df -i, mount, dmesg.
Lire les logs côté serveur : journalctl -u proxmox-backup autour de l’horodatage de l’échec.
Si ENOSPC : prune (dry-run d’abord), puis GC. Re-vérifier l’espace libre.
Si erreurs I/O : arrêter les écritures, réparer le stockage, puis vérifier les snapshots.
Relancer un backup représentatif pour une VM/CT et vérifiez-le immédiatement.

Checklist B: Quand vous devez récupérer de l’espace en sécurité

Lister la rétention et exécuter un prune dry-run pour un groupe que vous pouvez supprimer en toute sécurité.
Prune des snapshots intentionnellement (ne supprimez pas des fichiers au hasard).
Lancer la garbage collection pour récupérer les chunks.
Re-vérifier octets et inodes libres.
Ajuster les politiques de rétention pour ne pas répéter l’urgence chaque semaine.

Checklist C: Quand la vérification signale des erreurs de chunks

Déterminer si c’est uniquement le snapshot le plus récent ou un historique disséminé.
Vérifier dmesg et la santé du stockage (résultats scrub ZFS / SMART / logs RAID).
Si seulement le plus récent et en corrélation avec ENOSPC/crash : corriger la cause, relancer la sauvegarde, vérifier à nouveau.
Si disséminé : traiter comme incident d’intégrité du stockage. Arrêter les écritures. Remédier au matériel/stack de stockage.
Après remédiation : exécuter une vérification large et effectuer des tests de restauration pour les workloads critiques.

FAQ

1) Pourquoi PBS parle de « chunks » au lieu de fichiers ?

PBS déduplique et vérifie au niveau des chunks. Votre sauvegarde est un ensemble d’indexes référençant des chunks hachés, pas un fichier monolithique.
C’est pourquoi des chunks manquants cassent les restaurations même si « la plupart des données ont été uploadées ».

2) Si je prune des snapshots, pourquoi je ne récupère pas immédiatement de l’espace ?

Parce que prune supprime les références ; il ne supprime pas les chunks partagés qui peuvent encore être utilisés par d’autres snapshots. La garbage collection est ce qui récupère
les chunks non référencés.

3) Puis-je stocker des datastores PBS sur NFS ?

Vous pouvez, mais c’est un compromis de risque. Si votre serveur NFS est extrêmement fiable et optimisé pour les workloads riches en métadonnées, cela peut fonctionner.
En pratique, beaucoup d’histoires de « chunks manquants » remontent à un comportement de système de fichiers distant sous charge ou lors d’un basculement.

4) Quelle cible d’espace libre dois-je viser ?

Pour des opérations saines et un GC prévisible, prévoyez une marge significative. Si vous êtes régulièrement au-dessus de ~85% d’utilisation, attendez-vous à des ralentissements et à des échecs,
surtout sur les systèmes CoW. Dimensionnez capacité et rétention en conséquence.

5) J’ai ENOSPC mais je vois encore de l’espace libre. Comment ?

Les inodes, quotas, réservations ou contraintes spécifiques au système de fichiers peuvent provoquer ENOSPC. Vérifiez toujours df -i, et si vous utilisez ZFS, examinez les quotas/reservations de dataset.

6) Dois-je exécuter la vérification chaque nuit ?

La vérification est excellente, mais elle consomme de l’I/O. Sur les petits systèmes, planifiez-la pour qu’elle ne chevauche pas les sauvegardes lourdes ou le GC.
Pour les données critiques, une vérification fréquente plus des tests de restauration périodiques valent mieux qu’une foi aveugle.

7) Est-il sûr de corriger « datastore locked » en supprimant les fichiers de verrou ?

En général non. Les verrous sont souvent là parce qu’une tâche est en cours ou bloquée à cause d’I/O. Supprimer les verrous peut créer un état incohérent.
Trouvez la tâche, identifiez pourquoi elle est bloquée, puis résolvez cela.

8) Les erreurs de chunks signifient-elles toujours que mon stockage est corrompu ?

Pas toujours. Si le snapshot le plus récent a échoué pendant ENOSPC ou un crash, vous pouvez obtenir des chunks manquants pour ce seul snapshot.
Si des erreurs de chunks apparaissent sur de nombreux snapshots dans le temps, supposez un problème d’intégrité du stockage jusqu’à preuve du contraire.

9) Quelle est la meilleure habitude unique pour éviter les surprises de sauvegarde ?

Alerter sur l’utilisation du datastore (octets et inodes) et exécuter des tests de restauration planifiés. Les logs de succès de sauvegarde rassurent ; les restaurations prouvent.

Étapes suivantes (faites ceci, pas cela)

Si vous traitez des échecs de sauvegarde PBS aujourd’hui, effectuez ces étapes suivantes dans l’ordre :

Obtenir des preuves solides : récupérez l’erreur côté PBS depuis journalctl -u proxmox-backup et classez-la (espace vs intégrité vs verrou vs auth).
Corriger la capacité en premier : octets et inodes. Prune avec dry-run. Puis lancer garbage collection. Re-vérifier l’utilisation.
Vérifier après récupération : exécuter une verify ciblée sur les groupes en échec ; ne supposez pas que « la prochaine sauvegarde a réussi » signifie que tout est OK.
Arrêtez de faire confiance à un stockage instable : si vous voyez des motifs de corruption réels, mettez en pause les écritures et remédiez à la pile de stockage avant de créer d’autres sauvegardes douteuses.
Rendez la prochaine panne banale : ajoutez des alertes pour l’utilisation et les remontages RO, planifiez prune/GC intelligemment, et faites des tests de restauration.

L’objectif n’est pas une récupération héroïque. L’objectif est un système de sauvegarde si prévisible que la seule surprise est la rareté des incidents.
Et quand il échoue, vous voulez qu’il échoue bruyamment, rapidement, et avec suffisamment de détails pour le corriger avant d’avoir besoin d’une restauration.