Proxmox : Sauvegarder les VM Windows sans la douleur de VSS — Un workflow pratique

Ce que vous essayez réellement d’atteindre (et ce qu’il faut arrêter de prétendre)

La cohérence est un spectre, pas un binaire

Quand les gens débattent « crash-consistent vs application-consistent », ils manquent souvent la question pratique : à quoi doit ressembler votre restauration pour respecter vos RTO/RPO métiers et vos obligations d’audit ?

Pour une VM Windows, « application-consistent » signifie généralement que le système invité a eu la possibilité de vider les tampons du système de fichiers et de se coordonner avec les applications via VSS. C’est formidable quand ça marche. Mais ça peut aussi être un piège : VSS est un système distribué à l’intérieur d’une seule VM, avec plusieurs writers, et chaque writer a le pouvoir de ruiner votre soirée.

Les snapshots crash-consistents ne sont pas intrinsèquement mauvais. Si votre charge de travail les tolère (et beaucoup le font) et que vous testez les restaurations, ils peuvent être tout à fait acceptables. Le problème n’est pas la crash-cohérence ; le problème est de penser que vous avez l’application-cohérence alors que ce n’est pas le cas.

Les sauvegardes sont une charge de travail de stockage, pas une case à cocher

Les jobs de sauvegarde Proxmox ne se résument pas à « juste copier la VM ». Ce sont des tempêtes d’I/O coordonnées : beaucoup de lectures, beaucoup d’écritures, calcul de checksums (si vous faites les choses correctement) et tout cela sur un planning qui se heurte à tout le reste qui vous tient à cœur (maintenance nocturne, scans AV, jobs ETL, checkpoints de base de données, et cette mise à jour Windows qui refuse d’être ignorée).

Votre workflow de sauvegarde vit ou meurt en fonction du comportement du stockage : snapshots, dirty bitmaps, compression, découpage en chunks, profondeur de queue et si votre datastore cible est assez rapide pour absorber ce que vous lui envoyez.

Le système le plus fiable est celui qui échoue bruyamment et tôt

La dégradation silencieuse des sauvegardes, c’est comme finir par restaurer depuis « cette bonne sauvegarde d’il y a trois mois » en prétendant que tout va bien. Vous voulez que votre pipeline mette les problèmes en évidence immédiatement : timeouts de snapshot, échecs d’agent invité, problèmes de VSS writer, échecs de vérification du datastore et tests de restauration qui ne démarrent pas.

Une citation à afficher au-dessus de votre écran

Werner Vogels (idée paraphrasée) : « Tout échoue tout le temps ; concevez pour l’échec. »

Et oui, j’ai conscience de l’ironie : les sauvegardes sont littéralement un système conçu pour l’échec. L’autre ironie, c’est qu’on les construit souvent comme si l’échec était impoli et peu probable.

Faits intéressants et un peu d’histoire (parce que ça explique la douleur)

1. VSS a fait ses débuts avec Windows XP/Server 2003 comme tentative de Microsoft de standardiser la coordination des snapshots entre applications. Le modèle des writers est puissant, et aussi un point unique de déception collective.
2. VSS n’est pas un outil de sauvegarde ; c’est un cadre de coordination. Votre produit de sauvegarde (ou agent) doit toujours effectuer le mouvement réel des données.
3. Les échecs de « writer » sont souvent des symptômes en aval. Un writer de base de données échoue parce que le stockage est lent ; un writer système échoue parce que les permissions COM sont cassées ; un writer tiers échoue parce qu’il a planté mardi dernier et que personne ne l’a remarqué.
4. Les snapshots hyperviseur ne sont pas des snapshots Windows VSS. Proxmox peut snapshotter un disque virtuel sans que Windows soit au courant. C’est crash-consistent. Si vous voulez un vidage coordonné par Windows, il faut la coopération de l’invité.
5. QEMU Guest Agent est devenu la voie standard de « coopération invitée » dans les écosystèmes KVM, remplaçant des approches plus anciennes et plus désordonnées. Quand ça marche, c’est délicieusement ennuyeux.
6. Les drivers VirtIO ont été un tournant pour KVM sur Windows. Ils ont amélioré les performances de façon spectaculaire, mais ils ont aussi introduit une classe de bugs « mauvaise version de driver + mauvais mode disque/cache = comportement I/O étrange ».
7. Les snapshots ZFS sont bon marché ; la réplication ZFS n’est pas magique. Les snapshots sont des opérations méta ; la facture de performance arrive quand vous lisez et transmettez des blocs modifiés à grande échelle.
8. Proxmox Backup Server (PBS) est construit autour du chunking adressé par contenu. C’est pour ça qu’il déduplique bien et que CPU faible peut devenir votre goulot avant les disques.
9. « Fast Startup » de Windows a été conçu pour les postes de travail. Dans les VM, c’est un contributeur fréquent aux comportements déroutants au démarrage et à la cohérence des disques après restauration.

Le workflow pratique : moins d’échecs VSS, moins de surprises

Choisissez votre objectif de cohérence par VM (soyez explicite)

Arrêtez d’essayer de rendre chaque VM Windows « application-consistent » via VSS si ce n’est pas nécessaire. Catégorisez :

• Tier A (doit être app-consistent) : SQL Server, Exchange (si vous en avez encore, mes condoléances), contrôleurs de domaine AD DS (règles spéciales), applications métiers avec intégrité transactionnelle stricte.
• Tier B (app-consistent souhaitable) : serveurs de fichiers, serveurs IIS, serveurs applicatifs génériques.
• Tier C (crash-consistent acceptable) : nœuds web sans état, runners CI, jump boxes, environnements dev/test, postes de travail.

Vos outils de sauvegarde peuvent être différents selon les tiers. Ce n’est pas de l’hérésie ; c’est de l’ingénierie.

Approche par défaut : Proxmox Backup Server + QEMU Guest Agent (sans dépendance VSS)

Si votre douleur principale est VSS, la démarche la plus pragmatique est de découpler « sauvegarde VM » et « quiescence applicative ». Utilisez PBS (ou au minimum vzdump vers une cible de stockage saine) avec guest agent freeze/thaw pour la cohérence du système de fichiers, et gérez la cohérence applicative à l’intérieur de la VM avec des sauvegardes natives applicatives là où c’est nécessaire (sauvegardes SQL, etc.).

Cela réduit le rôle de VSS aux seuls endroits où VSS est vraiment l’outil adapté, plutôt que d’en faire une dépendance obligatoire pour chaque snapshot nocturne.

Pour le Tier A : faites des sauvegardes natives applicatives, puis des sauvegardes VM

Pour SQL Server, effectuez des sauvegardes SQL-aware (full/diff/log). Pour AD DS, comprenez la sémantique USN/restore et évitez les scénarios « oups on a rollbacké le DC ». Ensuite, prenez des sauvegardes au niveau VM pour une récupération bare-metal rapide. Les sauvegardes VM restent précieuses ; elles ne sont simplement pas la source faisant autorité pour la correction transactionnelle.

Paramètres Proxmox qui comptent (et ceux qui comptent surtout pas)

Le comportement des sauvegardes dans Proxmox dépend de :

• Mode de sauvegarde : snapshot vs suspend vs stop. Pour Windows, snapshot est généralement le meilleur—si votre stockage et le comportement de l’agent invité sont sains.
• Type de stockage : ZFS, LVM-thin, Ceph, NFS. Chacun change la sémantique des snapshots et les motifs d’I/O.
• Mode de cache disque et iothread : de mauvais choix peuvent amplifier la latence sous charge de sauvegarde.
• Chemin réseau vers PBS : si vous sauvegardez via le réseau, vous venez d’introduire un second goulot et un second domaine de panne.

Hygiène côté invité Windows qui réduit les échecs VSS « mystère »

Même si vous choisissez de ne pas dépendre de VSS pour chaque VM, Windows profite toujours d’une hygiène basique :

• Installer les VirtIO drivers actuels (stockage + réseau) et les garder alignés avec vos versions Proxmox/QEMU.
• Installer et activer QEMU Guest Agent et vérifier qu’il est réellement connecté.
• Maintenir une synchronisation temporelle Windows stable (hiérarchie de temps de domaine, pas de fournisseurs concurrents).
• Désactiver « Fast Startup » pour les VM serveur. Ça ne vous aide pas.
• Garder de l’espace disque libre raisonnable. Les pipelines snapshot/sauvegarde se comportent mal quand les volumes sont remplis à 98 %.

Blague #1 : Les VSS Writers sont comme ce collègue qui « a juste besoin de cinq minutes » puis bloque tout le train de sortie.

Mindset axé stockage : sauvegardez les sauvegardes

Si vous utilisez PBS, considérez-le comme du stockage de production. Cela signifie :

• Séparer le boot/système du datastore si possible.
• Utiliser ZFS ou RAID d’entreprise avec cache d’écriture correct (batterie-backed si RAID matériel ; ou simplement utiliser ZFS et dormir mieux).
• Surveiller les tâches de vérification et la santé du datastore comme vous le feriez pour une base de données.
• Tester régulièrement les restaurations. Pas trimestriellement. Régulièrement.

Tâches pratiques (commandes, sorties, décisions)

Ci-dessous des tâches pratiques que vous pouvez exécuter aujourd’hui. Chacune contient : commande, sortie exemple, ce que ça signifie, et la décision que vous en tirez.

Task 1 — Vérifier que Proxmox voit l’agent invité (la VM peut coopérer)

cr0x@server:~$ qm guest cmd 101 ping
{"return":{}}

Ce que ça signifie : L’agent est installé, en cours d’exécution dans Windows, et le canal virtio-serial fonctionne.

Décision : Si cela échoue (timeout ou « guest agent not running »), corrigez l’agent avant de blâmer les sauvegardes. Sans lui, le « freeze/thaw » et la coordination correcte ne se produiront pas.

Task 2 — Confirmer que la config VM ne vous sabote pas (flag agent, bus disque)

cr0x@server:~$ qm config 101 | egrep -i 'agent|scsi|virtio|cache|iothread'
agent: 1
scsi0: zfspool:vm-101-disk-0,cache=none,discard=on,iothread=1,ssd=1
scsihw: virtio-scsi-single

Ce que ça signifie : L’agent est activé ; le disque est sur virtio-scsi ; le mode cache est none ; iothread activé.

Décision : Préférez virtio-scsi + cache=none pour la plupart des charges serveur. Si vous voyez IDE/SATA pour des disques système en 2026, c’est de la dette technique avec intérêts.

Task 3 — Vérifier la santé de la cible de stockage de sauvegarde (statut datastore PBS)

cr0x@server:~$ proxmox-backup-manager datastore list
┌───────────┬──────────────┬────────┬──────────────┬──────────┐
│ Name      │ Path         │ Prune  │ GC           │ Comment  │
╞═══════════╪══════════════╪════════╪══════════════╪══════════╡
│ pbs-zfs   │ /datastore   │ keep…  │ daily        │ main     │
└───────────┴──────────────┴────────┴──────────────┴──────────┘

Ce que ça signifie : Le datastore existe et est géré.

Décision : Si vous n’avez pas de schedules prune/GC, vous accumulez des débris. Planifiez la capacité comme un adulte.

Task 4 — Vérifier l’utilisation disque du datastore (pression de capacité cause des bizarreries)

cr0x@server:~$ df -h /datastore
Filesystem      Size  Used Avail Use% Mounted on
rpool/datastore 7.3T  6.1T  1.2T  84% /datastore

Ce que ça signifie : 84 % utilisé. Ce n’est pas encore une urgence, mais ça sent le problème.

Décision : Au-dessus d’environ 85–90 % sur des cibles ZFS, les performances et la maintenance peuvent se dégrader. Resserrez la rétention, ajoutez de l’espace ou répartissez les charges entre datastores.

Task 5 — Vérifier la santé du pool ZFS sur l’hôte Proxmox (la corruption silencieuse est un risque de carrière)

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

Ce que ça signifie : Aucun défaut connu de device, resilver ou rapport de corruption de données.

Décision : Si ce n’est pas healthy, arrêtez d’optimiser les paramètres de sauvegarde et réparez le pool. Les sauvegardes sur un pool malade relèvent de l’art performance.

Task 6 — Inspecter les propriétés du dataset ZFS qui affectent l’I/O de sauvegarde

cr0x@server:~$ zfs get -o name,property,value compression,atime,recordsize,sync rpool/data
NAME       PROPERTY     VALUE
rpool/data compression  lz4
rpool/data atime        off
rpool/data recordsize   128K
rpool/data sync         standard

Ce que ça signifie : Des valeurs par défaut raisonnables pour le stockage VM (compression lz4, atime off).

Décision : Si sync=always est défini sur des datasets VM sans SLOG, les sauvegardes par snapshot peuvent ramper. Si compression=off, vous gaspillez I/O et espace pour beaucoup de charges Windows.

Task 7 — Lancer manuellement la sauvegarde d’une seule VM et observer le comportement

cr0x@server:~$ vzdump 101 --mode snapshot --storage pbs --compress zstd --notes-template '{{guestname}} {{vmid}}'
INFO: starting new backup job: vzdump 101 --mode snapshot --storage pbs --compress zstd
INFO: Backup started at 2026-02-04 01:12:30
INFO: status = running
INFO: VM Name: WIN-APP01
INFO: include disk 'scsi0' 'zfspool:vm-101-disk-0' 200G
INFO: creating Proxmox Backup Server archive 'vm/101/2026-02-04T01:12:30Z'
INFO: starting kvm to execute backup task
INFO: transferred 24.1 GiB in 00:03:12 (128.5 MiB/s)
INFO: backup finished successfully
INFO: Backup ended at 2026-02-04 01:15:45

Ce que ça signifie : La sauvegarde par snapshot est terminée ; le débit semble plausible.

Décision : Si le débit est anormalement bas, passez au playbook de diagnostic : est-ce la lecture disque, l’écriture disque, le CPU ou le réseau ?

Task 8 — Identifier si le réseau est votre facteur limitant (état des liaisons hôte)

cr0x@server:~$ ip -br link show
lo               UNKNOWN        00:00:00:00:00:00
eno1             UP             3c:ec:ef:11:22:33
bond0            UP             3c:ec:ef:11:22:33
vmbr0            UP             3c:ec:ef:11:22:33

Ce que ça signifie : Les interfaces sont up.

Décision : Si vous voyez des flaps, interfaces down, ou des MTU inattendus plus tard, votre « sauvegarde lentement aléatoire » n’est que le réseau qui fait son réseau.

Task 9 — Mesurer le débit réseau réel vers PBS (pas les impressions)

cr0x@server:~$ iperf3 -c pbs01 -t 10
Connecting to host pbs01, port 5201
[  5] local 10.10.10.21 port 54218 connected to 10.10.10.31 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-10.00  sec  9.35 GBytes  8.03 Gbits/sec  12   1.25 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  9.35 GBytes  8.03 Gbits/sec  12             sender
[  5]   0.00-10.00  sec  9.34 GBytes  8.02 Gbits/sec                  receiver

Ce que ça signifie : ~8 Gbit/s utilisables sur une liaison 10G, avec quelques retransmissions.

Décision : Si c’est 900 Mbit/s sur du « 10G », votre problème n’est pas VSS. C’est câblage, config NIC, config switch, MTU, ou une configuration de bond très créative.

Task 10 — Observer la latence I/O de l’hôte pendant les sauvegardes (la vérité est dans iostat)

cr0x@server:~$ iostat -x 2 5
Linux 6.8.12 (pve01) 	02/04/2026 	_x86_64_	(32 CPU)

Device            r/s     w/s   rkB/s   wkB/s  await  svctm  %util
nvme0n1         420.0   310.0 51200.0 42800.0   4.2    0.3   28.0
sdb              12.0    90.0   480.0  9200.0  45.6    1.2   96.0

Ce que ça signifie : sdb est saturé avec un await élevé. C’est un goulot. NVMe semble correct.

Décision : Si votre stockage VM ou la cible PBS repose sur le device saturé, les sauvegardes seront lentes et les opérations de snapshot peuvent expirer. Réparez le chemin disque lent avant de « tuner » les niveaux de compression.

Task 11 — Vérifier les logs de tâches Proxmox pour timeouts de snapshot et échecs d’agent

cr0x@server:~$ tail -n 60 /var/log/pve/tasks/active
UPID:pve01:000A1C2D:1F3A3E10:65C000B2:vzdump:101:root@pam:
status: running
command: vzdump 101 --mode snapshot --storage pbs --compress zstd

Ce que ça signifie : Le job est actif ; l’UPID est votre identifiant pour inspecter plus de détails.

Décision : Si le job stagne ici, regardez la latence disque et l’ingestion PBS. Si ça échoue, capturez les lignes d’erreur exactes — ne les résumez pas sur Slack par « sauvegarde cassée ».

Task 12 — Inspecter le journal pour les erreurs liées aux sauvegardes (kernel, stockage, NFS, PBS)

cr0x@server:~$ journalctl -u pvedaemon -u pvescheduler -u pveproxy --since "1 hour ago" | tail -n 40
Feb 04 01:14:10 pve01 pvedaemon[2387]: INFO: starting task UPID:pve01:000A1C2D:...
Feb 04 01:15:21 pve01 pvedaemon[2387]: INFO: VM 101 qmp command 'guest-fsfreeze-freeze' succeeded
Feb 04 01:15:23 pve01 pvedaemon[2387]: INFO: VM 101 qmp command 'guest-fsfreeze-thaw' succeeded
Feb 04 01:15:45 pve01 pvedaemon[2387]: INFO: end task UPID:pve01:000A1C2D:...: OK

Ce que ça signifie : Freeze/thaw réussi ; sauvegarde terminée.

Décision : Si vous voyez des échecs de freeze, vous revenez à la santé de l’agent invité. Si vous voyez des erreurs de stockage, arrêtez et corrigez le chemin de stockage sous-jacent.

Task 13 — Confirmer l’état des VSS writers côté Windows (quand vous en avez besoin)

cr0x@server:~$ qm guest exec 101 -- powershell -NoProfile -Command "vssadmin list writers"
{
  "exitcode": 0,
  "exited": 1,
  "out-data": "Writer name: 'System Writer'\r\n   State: [1] Stable\r\n   Last error: No error\r\n\r\nWriter name: 'WMI Writer'\r\n   State: [1] Stable\r\n   Last error: No error\r\n",
  "err-data": ""
}

Ce que ça signifie : Les writers sont stables pour l’instant.

Décision : Si un writer reste bloqué en état d’échec, vous pouvez parfois redémarrer le service lié. Mais si le problème revient, traitez-le comme un bug applicatif, pas comme un bug de sauvegarde.

Task 14 — Vérifier les journaux d’événements Windows pour des indices VSS (ne pas deviner)

cr0x@server:~$ qm guest exec 101 -- powershell -NoProfile -Command "Get-WinEvent -LogName Application -MaxEvents 20 | ?{$_.ProviderName -match 'VSS|Volsnap'} | Select-Object TimeCreated,ProviderName,Id,LevelDisplayName,Message | Format-List"
{
  "exitcode": 0,
  "exited": 1,
  "out-data": "TimeCreated : 2/4/2026 1:02:11 AM\r\nProviderName: VSS\r\nId          : 8193\r\nLevelDisplayName : Error\r\nMessage     : Volume Shadow Copy Service error: Unexpected error calling routine...\r\n",
  "err-data": ""
}

Ce que ça signifie : Vous avez une erreur VSS avec un ID que vous pouvez corréler avec des patterns d’échec connus.

Décision : Si l’erreur se répète au moment de la sauvegarde, corrigez VSS proprement (writers, permissions, provider) ou cessez de faire de VSS votre chemin critique et passez au workflow décrit ci‑dessus.

Task 15 — Valider le statut de vérification PBS (la détection de corruption n’est pas optionnelle)

cr0x@server:~$ proxmox-backup-manager task list --since "1 day ago" | head
┌────────────┬─────────┬───────────┬──────────┬──────────┬────────┐
│ Starttime  │ Endtime │ Worker ID │ Type     │ Status   │ User   │
╞════════════╪═════════╪═══════════╪══════════╪══════════╪════════╡
│ 01:30:00   │ 02:10:12│ verify    │ verify   │ OK       │ root@pam │
│ 01:00:00   │ 01:12:02│ prune     │ prune    │ OK       │ root@pam │
└────────────┴─────────┴────────┴─────────┴─────────┴────────┘

Ce que ça signifie : La vérification a été lancée et a réussi.

Décision : Si la vérification échoue, traitez-le comme une défaillance disque jusqu’à preuve du contraire. Ne vous contentez pas de relancer en priant l’univers.

Task 16 — Tester une restauration (le seul indicateur qui compte)

cr0x@server:~$ qmrestore /mnt/pbs/vm/101/2026-02-04T01:12:30Z 901 --storage zfspool
restore vma archive: PBS snapshot 'vm/101/2026-02-04T01:12:30Z'
creating VM 901
restore image: zfspool:vm-901-disk-0
progress 10%... 50%... 100%
restore successful

Ce que ça signifie : Vous pouvez restaurer une VM réelle à partir de l’ensemble de sauvegarde.

Décision : Démarrez-la dans un réseau isolé, vérifiez les services et confirmez l’intégrité applicative quand c’est nécessaire. Si vous ne faites jamais cela, votre stratégie de sauvegarde est un système de croyance.

Playbook de diagnostic rapide : trouver le goulot en quelques minutes

C’est l’ordre qui trouve rapidement le vrai problème. Pas l’ordre qui crée le plus de tickets.

Première étape : déterminer quel type d’échec vous avez

• Le job de sauvegarde échoue rapidement (secondes à une minute) : authentification, permissions, chemin de stockage, datastore PBS indisponible, agent manquant.
• Le job de sauvegarde se bloque ou rampe (minutes à heures) : latence disque, ingestion PBS CPU/disque, débit réseau, opérations de snapshot bloquées par le stockage.
• La sauvegarde « réussit » mais la restauration est cassée : problèmes de cohérence, système de fichiers invité corrompu, ou vous avez sauvegardé la mauvaise chose (disques exclus, mauvais VMID, etc.).

Deuxième étape : isoler le domaine du goulot (disque hôte, disque PBS, CPU, réseau, invité)

1. Latence stockage hôte : exécutez iostat -x pendant la sauvegarde. Await élevé et ~100 % %util sur les devices concernés signifie que vous êtes lié par l’I/O.
2. Côté ingestion PBS : si les disques hôtes vont bien, vérifiez le CPU et les disques de PBS. Chunking + compression + chiffrement peuvent rendre le système bound CPU sur du matériel modeste.
3. Débit réseau : exécutez iperf3 entre l’hôte et PBS. Si c’est lent, les sauvegardes seront lentes. Surprise.
4. Coopération invité : si les snapshots échouent ou expirent au freeze, vérifiez la connectivité du QEMU Guest Agent et la stabilité de Windows.

Troisième étape : identifier le goulet d’étranglement spécifique

• Si la latence monte sur le stockage VM : déplacez les fenêtres de sauvegarde, réduisez la concurrence, utilisez des vdevs plus rapides ou séparez la lecture I/O de sauvegarde de l’I/O de production (pools différents).
• Si PBS est bound CPU : envisagez plus de cœurs, vérifiez les réglages BIOS power, assurez-vous qu’AES-NI est disponible si vous utilisez le chiffrement, ajustez la compression (niveaux zstd) ou réduisez la concurrence.
• Si le réseau est le goulet : corrigez MTU, LACP, buffers de switch, offloads NIC ; ou arrêtez d’envoyer des sauvegardes sur une liaison congestionnée pendant les jobs critiques.
• Si VSS est le goulet : cessez de faire de VSS votre dépendance par défaut. Utilisez QGA freeze pour une cohérence de base ; utilisez des sauvegardes natives applicatives pour les Tier A.

Blague #2 : Si les performances de vos sauvegardes « dépendent de la météo », félicitations — vous avez construit un cloud, juste sans le budget.

Erreurs courantes : symptômes → cause racine → correction

1) Les sauvegardes échouent de manière intermittente avec « guest-fsfreeze-freeze timeout »

Symptômes : Les logs Proxmox montrent un timeout de la commande freeze ; la VM semble « normale » par ailleurs.

Cause racine : QEMU Guest Agent mal installé, service bloqué dans Windows, ou canal virtio-serial manquant/bloqué. Parfois l’agent est installé mais pas activé dans la configuration Proxmox.

Correction : Assurez-vous de agent: 1 dans la config VM, vérifiez qm guest cmd <vmid> ping, réinstallez/mettre à jour QGA sous Windows et confirmez l’existence du périphérique VirtIO serial dans le Gestionnaire de périphériques.

2) Les sauvegardes « réussissent » mais la restauration Windows démarre sur CHKDSK ou a des volumes sales

Symptômes : La restauration prend des heures au premier démarrage ; les logs montrent une récupération NTFS ; les applications se plaignent.

Cause racine : Vous prenez des snapshots crash-consistents de charges d’écriture lourdes et attendez une cohérence applicative. Ou les paramètres de cache/disque Windows sont dangereux et les tampons ne sont pas flushés lors du snapshot.

Correction : Utilisez au minimum QGA freeze/thaw. Pour le Tier A, exécutez des sauvegardes natives applicatives (SQL) et traitez les sauvegardes VM comme images de récupération rapide, pas comme journaux transactionnels.

3) Le VSS writer « System Writer » échoue uniquement pendant les fenêtres de sauvegarde

Symptômes : VSS stable à midi, cassé à 1h du matin. Event ID 8193/12289 apparaît autour du moment de la sauvegarde.

Cause racine : Pression de ressources : pics de latence stockage, antivirus scannant les snapshots VSS, ou un provider VSS tiers qui interfère.

Correction : Réduisez la concurrence des sauvegardes, déplacez la fenêtre de sauvegarde, augmentez les IOPS, excluez les répertoires liés à VSS dans l’AV selon les recommandations du fournisseur, et supprimez les providers VSS inutiles si approprié.

4) Les sauvegardes sont terriblement lentes après « amélioration de la compression »

Symptômes : Le débit chute ; le CPU grimpe ; les jobs se chevauchent en heures ouvrées.

Cause racine : Niveau de compression trop élevé pour le CPU disponible (hôte ou PBS). Le chunking + compression est du travail CPU, pas de l’espace gratuit.

Correction : Utilisez une compression sensée (zstd par défaut est généralement correcte). Augmentez le CPU ou réduisez la concurrence. N’« optimisez » pas sans mesurer.

5) Le datastore PBS se remplit même si la purge est configurée

Symptômes : L’utilisation disque augmente ; prune s’exécute « OK » mais l’espace ne revient pas.

Cause racine : Le garbage collection ne s’exécute pas ou ne se termine pas ; ou vous conservez trop car votre politique est aspirationnelle au lieu d’être mathématique.

Correction : Assurez-vous qu’un schedule GC existe et se termine. Re-vérifiez les règles de rétention et la fréquence réelle des sauvegardes. Planifiez la capacité avec de la marge, pas de l’espoir.

6) Les snapshots de sauvegarde figent la VM (les utilisateurs le remarquent)

Symptômes : Pauses courtes mais pénibles lors de la création du snapshot ; latence RDP ; timeouts applicatifs.

Cause racine : Latence stockage et comportement de commit de snapshot sous charge ; parfois paramètres de cache d’écriture ou SLOG insuffisant pour charges sync-heavy sur ZFS.

Correction : Réduisez la concurrence, isolez l’I/O de sauvegarde, assurez une topologie ZFS adaptée (mirrors pour IOPS) et évitez les réglages sync pathologiques. Validez le mode cache disque et la configuration iothread.

7) Les restaurations sont lentes même si les sauvegardes étaient rapides

Symptômes : L’ingestion de sauvegarde est bonne, la restauration traîne.

Cause racine : Le stockage cible de restauration est plus lent que la cible de sauvegarde ; ou pression ARC ZFS, fragmentation, ou un vdev lent en cause.

Correction : Mesurez le chemin de restauration. Si vous restaurez sur du stockage de production, ce stockage doit être assez rapide pour reconstruire la VM à la demande. « Les sauvegardes sont rapides » n’équivaut pas à « les restaurations sont rapides ».

Trois mini-récits du monde de l’entreprise (ce que vous héritez)

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

Ils avaient un cluster Proxmox propre, une belle boîte PBS, et des sauvegardes nocturnes partout. Le tableau de bord de sauvegarde était vert la plupart du temps. La direction était contente. L’équipe ops se voyait confier « des initiatives plus stratégiques », ce qui est l’euphémisme corporatif pour « on ne va pas recruter ».

Puis une VM de serveur de fichiers Windows a planté. Pas de façon spectaculaire—juste une mauvaise mise à jour combinée à un plantage de driver. Restauration facile, non ? Ils ont restauré la sauvegarde de la nuit précédente dans un nouveau VMID, attaché le réseau, et les utilisateurs étaient opérationnels en 20 minutes. High five. Ticket clos.

Deux jours plus tard, quelqu’un a remarqué qu’un ensemble de partages départementaux avait des modifications manquantes. Pas des fichiers manquants—des modifications manquantes. Des versions rétablies. Les gens disaient « on a l’impression qu’il a rollbacké ». Cette phrase, au passage, fait tressaillir tout ingénieur stockage.

La mauvaise hypothèse : ils croyaient que les sauvegardes étaient application-consistent parce que le produit disait « snapshot backup ». En réalité, l’agent invité ne fonctionnait pas sur cette VM. Ils prenaient des snapshots crash-consistents pendant une activité d’écriture élevée, et les restaurations revenaient parfois avec un replay du système de fichiers qui ne reflétait pas ce que les utilisateurs attendaient. Pas tout le temps. Juste assez pour être terrifiant.

La correction n’a pas été dramatique. Ils ont installé et vérifié QEMU Guest Agent, activé freeze/thaw pour les serveurs de fichiers, et ajouté un test de boot de restauration régulier. La partie difficile a été le changement culturel : « des jobs de sauvegarde verts » ont cessé d’être l’objectif. Les restaurations vérifiées sont devenues l’objectif.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux

Un autre service voyait les fenêtres de sauvegarde empiéter sur les heures de bureau. Quelqu’un—bonne volonté, compétences correctes—décida de « optimiser la compression ». Ils ont monté les niveaux zstd et activé le chiffrement partout parce que « sécurité ». Ce sont des objectifs valables. Le problème, c’est que le matériel se fiche de vos objectifs.

Cette semaine-là, la durée des sauvegardes a doublé. Puis triplé les nuits chargées. La latence de production a augmenté pendant les fenêtres de sauvegarde parce que les CPUs hôtes passaient des cycles à compresser et à checksommer, pendant que les files d’attente de stockage s’allongeaient. L’équipe a répondu en augmentant la concurrence des sauvegardes pour « finir plus vite ». C’est à ce moment que le système a entamé son arc vilain.

Maintenant ils avaient plus de VMs sauvegardées en même temps, toutes lisant intensivement le stockage de production, toutes traitant la compression CPU-intensive, toutes envoyant du trafic sur les mêmes uplinks. Les performances ont empiré. Les timeouts ont augmenté. Certaines VMs ont commencé à échouer les snapshots parce que le stockage était trop occupé pour répondre à temps. Le tableau de bord est passé à une nuance festive de rouge.

La correction a été de revenir sur l’« optimisation » et de re-mesurer. Ils ont remis la compression à un niveau raisonnable, gardé le chiffrement uniquement là où c’était requis, réduit la concurrence et déplacé les systèmes Tier A les plus lourds vers des fenêtres dédiées. Puis ils ont upgradé le CPU de PBS—parce que parfois le bon choix d’ingénierie est d’acheter les ressources manquantes plutôt que d’essayer de tromper la physique.

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

Une équipe d’entreprise avait l’habitude, un peu vieille école, d’exécuter chaque mois un drill de restauration pour un petit ensemble de VM Windows représentatives. Pas juste « restauration terminée », mais « la VM boote, les services démarrent, les checks d’intégrité applicative passent ». Ils faisaient tourner quels systèmes tester et gardaient un runbook court de ce qu’est un état « bon ».

C’était ennuyeux. C’était planifié. Ça créait un petit travail prévisible. Et ça les rendait impopulaires auprès d’un groupe précis : ceux qui croyaient que les sauvegardes sont « set-and-forget ».

Puis leur fournisseur de stockage a poussé une mise à jour firmware qui a introduit des pics de latence intermittents sous charges de lecture soutenues. La production ne le remarquait pas toujours. Les sauvegardes, si. Les jobs de vérification PBS ont commencé à échouer occasionnellement, et quelques snapshots ont commencé à expirer.

Parce qu’ils faisaient des drills de restauration, le problème est apparu comme « la restauration a pris 4x plus de temps que d’habitude » avant d’apparaître comme « on ne peut pas restaurer ». Cette différence compte. Ils ont rollbacké le firmware, ajusté provisoirement les plannings de sauvegarde, et évité le pire : découvrir une corruption ou des chunks illisibles pendant un vrai incident.

La pratique ne paraissait pas brillante. Elle a toutefois été la raison pour laquelle ils ont passé un week-end tranquille au lieu d’un événement qui ferait refaire des CV.

Listes de contrôle / plan pas à pas

Étapes pas à pas : établir une baseline à faible drame

1. Classifiez les VMs par tiers (A/B/C) selon les besoins de cohérence applicative.
2. Installez les VirtIO drivers et QEMU Guest Agent sur chaque VM Windows. Vérifiez avec qm guest cmd <vmid> ping.
3. Standardisez la configuration disque : contrôleur virtio-scsi, cache=none, activer iothread si approprié.
4. Choisissez les cibles de sauvegarde délibérément :
   • PBS pour la déduplication, la vérification et une gestion de rétention saine.
   • Datastore/pool séparé si possible ; les sauvegardes en compétition avec la production sont un mauvais plan connu.
5. Définissez des politiques de rétention qui correspondent à la capacité (daily/weekly/monthly) et vérifiez l’existence de prune + GC schedules.
6. Limitez la concurrence initialement. Commencez petit, mesurez, puis augmentez. Ne commencez pas par « toutes les VMs en même temps ».
7. Implémentez des tests de restauration :
   • Au moins un test de boot de restauration hebdomadaire sur des systèmes tournants.
   • Systèmes Tier A : inclure des étapes de validation au niveau applicatif.

Checklist : paramètres VM Windows qui réduisent les bizarreries de sauvegarde

• QEMU Guest Agent installé, en cours d’exécution et activé dans Proxmox.
• Drivers VirtIO stockage à jour ; éviter les contrôleurs legacy pour les disques système.
• Désactiver Fast Startup pour les VM serveur.
• Assurer un espace libre adéquat sur les volumes (éviter de vivre à 95 % rempli).
• Revue des exclusions AV pour les opérations de backup/snapshot lorsque pertinent (avec précaution, pas aveuglément).
• Synchronisation temporelle cohérente (hiérarchie de domaine ; éviter les sources de synchronisation concurrentes).

Checklist : hygiène opérationnelle PBS

• Tâches de vérification planifiées et surveillées.
• Schedules prune et GC existants et qui se terminent.
• Utilisation des datastores monitorée ; marge maintenue.
• Tests de restauration périodiques effectués depuis PBS, pas depuis « une autre copie ».
• Le matériel dispose d’un CPU suffisant pour chunking/compression/chiffrement.

FAQ

1) Puis-je sauvegarder des VM Windows sur Proxmox sans utiliser VSS du tout ?

Oui. Les sauvegardes au niveau VM par snapshot peuvent être crash-consistentes, et avec QEMU Guest Agent freeze/thaw elles peuvent être cohérentes au niveau système de fichiers sans VSS. Pour les applications transactionnelles, utilisez des sauvegardes natives applicatives.

2) QEMU Guest Agent est-il « suffisant » pour des serveurs Windows ?

Pour coordonner freeze/thaw et arrêts propres, oui—lorsqu’il est installé correctement et maintenu à jour. Ce n’est pas un substitut aux sauvegardes SQL-aware ou autres protections spécifiques applicatives.

3) Dois-je utiliser le mode snapshot, suspend ou stop pour Windows ?

Le mode snapshot est la recommandation par défaut. Suspend/stop peut améliorer la cohérence mais augmente le downtime ou le temps de stun. Utilisez stop uniquement si vous acceptez le downtime ou si vous ne pouvez pas faire confiance à l’état invité.

4) Pourquoi mes sauvegardes deviennent-elles plus lentes avec le temps alors que rien n’a changé ?

En général quelque chose a changé. Capacité remplie, fragmentation ZFS accrue, GC datastore PBS ralenti, retransmissions réseau augmentées, ou la concurrence des sauvegardes a glissé à la hausse. Mesurez la latence I/O et vérifiez les schedules en premier.

5) Dois-je désactiver Windows Fast Startup sur les VM serveur ?

Oui, dans la plupart des cas. Il est optimisé pour la commodité des clients, pas pour des événements de cycle de vie de VM et la prévisibilité des restaurations.

6) Combien de jobs de sauvegarde concurrents devrais-je lancer ?

Commencez par 1–2 par hôte, mesurez la latence stockage et la durée des sauvegardes, puis augmentez. Si la latence monte et que les VMs bégayent, vous en faites trop. La concurrence n’est pas un trait de personnalité.

7) La vérification PBS échoue parfois. Est-ce « normal » ?

Non. Traitez les échecs de vérification comme un signal de problème de stockage, mémoire ou disque jusqu’à preuve du contraire. Les corruptions intermittentes ne s’améliorent pas avec de l’optimisme.

8) Des sauvegardes crash-consistentes sont-elles acceptables pour des contrôleurs de domaine Active Directory ?

Soyez prudent. AD a des sémantiques de restauration spécifiques. Si vous vous fiez aux snapshots VM, validez votre approche et envisagez des sauvegardes d’état système et des procédures de restauration autoritaire/non-autoritaire.

9) Dois-je sauvegarder vers NFS au lieu de PBS ?

Vous pouvez, mais vous perdez le workflow de chunking/dédoublonnage/vérification de PBS. NFS peut être acceptable s’il est robuste et surveillé, mais c’est aussi une source classique d’incidents « ça marche jusqu’au jour où ça ne marche plus ».

10) Quelle est l’amélioration la plus précieuse que je peux apporter en premier ?

Les tests de restauration. La deuxième amélioration la plus précieuse est l’instrumentation—savoir si vous êtes lié par disque, CPU ou réseau lorsque les sauvegardes s’exécutent.

Conclusion : prochaines étapes pratiques

Si vos sauvegardes Windows sur Proxmox ressemblent à une anthology d’horreur VSS, arrêtez de faire de VSS votre dépendance universelle. Utilisez un workflow qui par défaut réalise des sauvegardes au niveau VM avec la coopération de l’agent invité, et réservez VSS et les sauvegardes applicatives pour les systèmes qui en ont réellement besoin.

Faites ces étapes :

1. Choisissez 3 VM Windows : une Tier A, une Tier B, une Tier C. Validez la connectivité QEMU Guest Agent et les paramètres disque/contrôleur.
2. Exécutez des sauvegardes manuelles en surveillant iostat et le débit réseau. Identifiez le domaine réel du goulot.
3. Configurez la vérification PBS + les schedules prune/GC (et alertez en cas d’échec).
4. Effectuez un test de restauration cette semaine. Démarrez la VM. Confirmez que le service fonctionne. Notez ce que signifie « bon ».
5. Puis scalez : ajustez la concurrence, la rétention et le matériel en fonction des contraintes mesurées, pas de l’espoir.

Les sauvegardes devraient être ennuyeuses. Si elles ne le sont pas, elles essaient de vous dire quelque chose. Écoutez avant que l’incident ne le fasse.