Le mode snapshot de vzdump ne prend aucun snapshot de votre disque : il pose un filtre devant les écritures de la VM, et ce filtre peut lui faire attendre le serveur de sauvegarde.
Au démarrage du backup, QEMU installe un filtre copy-before-write dans sa couche bloc. Quand la VM écrit sur un bloc pas encore sauvegardé, l'ancienne donnée part d'abord vers la cible, et l'écriture reste bloquée jusqu'à la fin de cette opération. La vitesse d'écriture du guest sur ces blocs est limitée par celle de la cible. Le geste : vérifier que les pics d'await du guest coïncident avec les backups, puis activer le fleecing sur un stockage local rapide. L'option existe depuis Proxmox VE 8.2 et reste désactivée par défaut.
Ce mécanisme concerne les VM. Un conteneur LXC en mode snapshot utilise un vrai snapshot du stockage, et le fleecing ne s'applique pas à lui.
On a suivi ce chemin en août 2026 sur une VM en production : MariaDB, mirror de deux NVMe, cible Proxmox Backup Server.
Deux ou trois minutes de site figé
Le signalement : le site se fige deux ou trois minutes, les requêtes MySQL restent bloquées, et cela revient à chaque sauvegarde. Cette durée est un ressenti rapporté, sans mesure. Un passage de la cadence de trente à vingt minutes n'avait pas fait cesser les gels. La cadence répartit les exécutions et ne change rien à chacune.
Le disque de la VM, vu par sar
sar garde un historique, ce qui évite d'attendre le prochain gel :
# Dans la VM. Sous Debian 13, l'historique est dans /var/log/sysstat (DD : jour du mois)
sar -d -f /var/log/sysstat/saDD
Sous Debian 13, la collecte est désactivée à l'installation (ENABLED="false" dans /etc/default/sysstat), et ne garde ensuite que sept jours (HISTORY=7). Si personne ne l'a activée, il n'y a rien à relire.
Sur une douzaine de jours d'août, le relevé montrait jusqu'à 48 pics par jour, dans les intervalles finissant à X:10 et X:40, avec un await de 26 à 139 ms contre 0,30 ms le reste du temps. Sur les fenêtres comparées à charge égale, environ 30 écritures par seconde :
| Relevé côté guest | Hors backup | Pendant le backup |
await | 0,30 ms | 100 à 139 ms |
aqu-sz | 0,01 | 3,0 à 4,4 |
Le disque répond plusieurs centaines de fois plus lentement alors que la VM ne lui demande rien de plus. Une latence haute avec un tps faible désigne une attente imposée de l'extérieur du guest. Insuffisant pour conclure : un pool saturé par une VM voisine donne le même profil.
Écarter le stockage et l'hôte
Le stockage n'est pas écarté par une mesure : notre dossier ne contient aucun relevé du pool de l'hôte pendant les fenêtres. Sur votre hôte, iostat -x pendant un backup tranche ce point.
Le %steal restait entre 0,05 et 0,20 %, ce qui écarte la contention CPU de l'hôte.
Une erreur à notre compte chez SHPV : pendant cette enquête, on a signalé à tort le plafond de l'ARC ZFS de l'hôte, puis retiré ce signalement. Il était bas volontairement et correct sur ce nœud, dont la mémoire sert surtout aux VM. Sur les machines qu'on opère, on relève désormais la cadence des pics d'await avant toute hypothèse.
Le guest agent n'était pas actif sur cette VM, ce qui écartait le gel du système de fichiers, autre cause de blocage au début d'un backup. Quand il est actif, le journal de la tâche porte la ligne issuing guest-agent 'fs-freeze' command.
Les pics de sar calés sur le pvescheduler
La cadence des pics se compare ensuite au journal de l'hôte :
# Sur l'hyperviseur
journalctl -u pvescheduler --since yesterday --grep "Starting Backup of VM"
grep -E '^vzdump|mode|fleecing' /etc/pve/jobs.cfg
Le pvescheduler lançait le backup de cette VM à X:02 et X:32, pour trois à dix minutes. Les fenêtres de sar tombaient exactement dessus. Le job était en mode snapshot, fleecing à 0. Aucune erreur de réglage : ce sont les valeurs par défaut du man de vzdump.
Le filtre copy-before-write, bloc par bloc
La documentation Proxmox l'écrit : « The guest write blocks until this operation is finished so guest IO to not-yet-backed-up sectors will be limited by the speed of the backup target. »
Le mot « snapshot » trompe, parce qu'il évoque le stockage. La même page précise que cette sauvegarde donne une sémantique proche du snapshot sur n'importe quel stockage. La cohérence vient de QEMU, qui copie l'ancienne donnée au moment où elle allait disparaître.
Le code ajoute un détail absent de ce chapitre : la taille du bloc. Vers un PBS, le patch pve-qemu la fixe à 4 Mio (PROXMOX_BACKUP_DEFAULT_CHUNK_SIZE; // Hardcoded (4M)). Une écriture de 4 Kio sur un bloc pas encore traité déclenche donc le traitement d'un morceau mille fois plus gros. Sur ce lien, qui transférait à 95 Mo/s, 4 Mio prennent 44 ms de transfert seul, calcul fait, avant hachage et compression. L'ordre de grandeur colle aux pics relevés sans le prouver.
Ce que 100 ms font aux commits de MariaDB
MariaDB tournait avec innodb_flush_log_at_trx_commit à 1, sa valeur par défaut : le journal est écrit et vidé sur disque à chaque transaction. Par le calcul, sans relevé, passer de 0,3 à 100 ms par écriture divise par plus de 300 le débit de commits possible en série. L'empilement des connexions, puis le site figé, reste une déduction : ni les connexions ni les commits n'ont été relevés pendant un gel.
Passer ce paramètre à 2 soulagerait les commits, mais la documentation MariaDB rappelle qu'une coupure peut alors perdre la dernière seconde de transactions. On échangerait de la durabilité contre un problème dont la source est ailleurs, et le reste du réglage de MariaDB n'y change rien.
Le job déplacé à 03:00, l'await retombe
Avant de toucher au mécanisme, on a déplacé le job à 03:00 le jour du diagnostic. Dix minutes après le début de la dernière exécution, l'await était retombé à 0,20 ms.
Cette lecture ne prouve rien à elle seule : hors backup, l'await était déjà à 0,30 ms. Le diagnostic repose sur la coïncidence des fenêtres et le mécanisme documenté, sans mesure qui isole le filtre sur cette VM. Le fleecing, alors seulement proposé, a été activé plus tard et la cadence de trente minutes rétablie. Un relevé d'octobre montre une image de fleecing à chaque passage et aucun échec qui lui soit imputable dans les journaux conservés, mais l'await n'y a pas été remesuré : aucune mesure avant et après à publier. Pour le gain, reste la documentation Proxmox : l'option « can help guest IO performance and even prevent hangs in certain scenarios », sans chiffre.
Le déplacement a un coût : une sauvegarde par nuit au lieu d'une toutes les trente minutes. Si cette fréquence compte pour votre stratégie de sauvegarde, il faut traiter le mécanisme.
Activer le fleecing sans se créer un autre incident
Le fleecing garde l'ancienne donnée dans une image locale au lieu de l'envoyer directement à la cible. Le guest reprend la main après la copie locale, et le backup lit ensuite à son rythme.
# Un essai manuel sur une VM
vzdump 123 --fleecing enabled=1,storage=local-lvm
# Un job existant, par l'API (ou Datacenter, Backup, onglet Advanced)
pvesh set /cluster/backup/<id> --fleecing enabled=1,storage=local-lvm
# Repli pour tout le nœud, dans /etc/vzdump.conf
# fleecing: enabled=1,storage=local-lvm
La documentation demande un stockage local rapide, avec provisionnement fin et discard : LVM-thin, RBD, ZFS avec sparse 1, beaucoup de stockages fichier. Sur LVM classique ou ZFS sans sparse, la taille complète du disque source est réservée d'avance : vérifiez /etc/pve/storage.cfg avant.
Côté espace, seuls les blocs écrasés pendant la fenêtre sont copiés, une fois chacun, puis libérés une fois sauvegardés. Le filtre du fleecing ne reçoit pas le minimum de 4 Mio du job : il travaille au plus grand de 64 Kio et de la taille de cluster de l'image. Le pire cas documenté reste la taille du disque, si le guest le réécrit entièrement pendant que le backup traite un autre disque. Mesurez sur votre charge. La documentation recommande un stockage dédié, pour qu'une saturation fasse échouer le backup sans toucher les autres guests.
Le mode de panne change aussi. Sans fleecing, le job est créé avec ON_CBW_ERROR_BREAK_GUEST_WRITE : une copie en échec fait échouer l'écriture du guest. Avec fleecing, le patch passe on-cbw-error=break-snapshot et cbw-timeout=45 : sur erreur ou après 45 secondes, c'est le backup qui s'annule. Le commentaire du code l'assume, « it's better to break backup than guest writes ». La VM y gagne, mais un backup annulé devient le symptôme à surveiller : alertez sur l'échec des jobs.
Dernier contrôle, la version : Proxmox VE 8.3 et 8.4 ont corrigé des cas d'I/O guest bloquées après un échec de fleecing. Sur une version plus ancienne, mettez à jour d'abord.
Quand le fleecing ne suffit pas
Changer de mode ne retire pas le filtre : stop repose aussi sur le live backup, et suspend appelle ensuite le mode snapshot.
Le fleecing n'a pas toujours suffi. Sur le forum Proxmox, un utilisateur décrit un serveur MySQL où il a réduit les blocages sans les supprimer, avant de les voir disparaître après un retour aux réglages MySQL par défaut et l'activation du discard sur le disque de la VM, cause non établie. Ce témoignage suffit à ne pas vendre l'option comme un remède garanti.
Si l'await ne redescend pas une fois l'option active, le goulot a changé de place. Regardez alors le stockage de fleecing avec iostat sur l'hôte, et le débit vers la cible avec proxmox-backup-client benchmark, qui mesure la vitesse d'envoi TLS quand on lui indique un dépôt.
Sources
- Proxmox VE, Backup and Restore : modes de backup, fleecing, stockages, version 9.2.13 lue le 2 novembre 2026
- Man de vzdump : valeurs par défaut, fleecing limité aux VM
- Roadmap Proxmox VE : fleecing en 8.2 (24 avril 2024), corrections en 8.3 et 8.4
- Patch pve-qemu, fleecing :
break-snapshot, délai de 45 secondes, granularité du job - Patch pve-qemu, backup : bloc de 4 Mio vers un PBS
- QEMU, block-core.json : filtre
copy-before-writeet ses options - QEMU, block-copy.c : calcul de la taille de cluster
- VZDump.pm : ligne de journal
Starting Backup of VM - QemuServer.pm : ligne de journal
fs-freeze - PBS, Backup Client : sous-commande
benchmark - sysstat Debian, templates : collecte désactivée par défaut
- MariaDB, variables InnoDB : valeurs de
innodb_flush_log_at_trx_commit - Forum Proxmox, VM backups et ZFS : fleecing partiellement efficace, réponse de l'équipe Proxmox
