Proxmox sur ZFS : la stratégie de sauvegarde qui ne ment pas (snapshots vs véritables sauvegardes)

décembre 28, 2025 • février 3, 2026 • Lecture : 30 min • Views: 11

Cet article vous a aidé ?

Si vous exécutez Proxmox sur ZFS, vous pouvez créer des snapshots si rapidement que cela en devient presque de la triche. Et c’est le piège.
Le jour où vous aurez besoin d’une véritable restauration — après un problème de pool, un rm fait par erreur, ou une mise à jour de l’hyperviseur qui tourne mal — votre « stratégie de snapshots » risque de s’avérer être une stratégie pour se sentir serein, pas pour récupérer les données.

Les sauvegardes sont un produit : elles doivent livrer des restaurations. Les snapshots ZFS sont une fonctionnalité : elles offrent de la commodité. Arrêtez de les confondre.
Voici le mode d’emploi sans concession qui maintient les clusters Proxmox honnêtes.

La revendication centrale : les snapshots ne sont pas des sauvegardes

Un snapshot ZFS est une référence ponctuelle aux blocs du même pool. C’est fantastique pour un rollback rapide et pour les moments « oups ».
Mais il vit et meurt avec le pool. Si le pool disparaît, vos snapshots disparaissent. Si le pool est chiffré et que la clé disparaît, vos snapshots sont toujours « là » de la même manière que vos fichiers sont « là » sur un disque que vous ne pouvez pas déverrouiller : techniquement, spirituellement, pas opérationnellement.

Une sauvegarde est autre chose : elle est indépendante. Elle est stockée ailleurs, soumise à des modes de défaillance différents, et elle est régulièrement validée par des restaurations.
Si votre « sauvegarde » ne quitte pas le domaine de défaillance, vous n’avez pas de sauvegarde ; vous avez une machine à remonter le temps attachée à la même voiture qui vient de tomber dans le lac.

Le test opérationnel est brutal : si la carte mère de l’hyperviseur grille, pouvez-vous restaurer vos VM sur un autre hôte sans forensique héroïque ?
Si la réponse commence par « eh bien, les snapshots sont sur le pool », ce n’est pas un plan. C’est une anecdote.

Blague n°1 : Un snapshot, c’est comme un bouton « sauvegarder » qui ne fonctionne que si votre portable ne tombe pas à la mer. Belle fonctionnalité, récupération en cas de catastrophe discutable.

Faits intéressants et courte histoire (qui aide réellement à décider)

Les snapshots ZFS sont copy-on-write : ils ne « figeant » pas les données en les copiant ; ils préservent des références de blocs et écrivent de nouveaux blocs pour les changements.
ZFS a été conçu avec des checksums de bout en bout : les blocs de données et de métadonnées sont contrôlés par checksum, donc la corruption silencieuse est détectable lors des lectures et des scrubs.
La filiation Solaris compte : ZFS a grandi dans des environnements d’entreprise où « rollback » et « réplication » étaient des idées distinctes — snapshots et send/receive jouent des rôles différents.
zfs send est un streaming basé sur des snapshots : la réplication et beaucoup de flux de travail « type sauvegarde » utilisent les snapshots comme unité de transfert.
Les scrubs ZFS sont des lectures de patrouille : ce ne sont pas des sauvegardes, mais ils permettent à ZFS de trouver de la bit rot avant qu’elle ne déclenche un événement de restauration.
Historiquement, Proxmox s’appuyait sur vzdump : les sauvegardes classiques étaient des archives fichiers vers des cibles de stockage ; les déploiements modernes utilisent de plus en plus Proxmox Backup Server (PBS) pour des sauvegardes fragmentées et dédupliquées.
Les snapshots ont gagné en popularité parce qu’ils sont peu coûteux : la sensation de « coût quasi nul » pousse les équipes à les surutiliser comme rétention, puis elles sont surprises par la comptabilité d’espace.
Le RAID n’est toujours pas une sauvegarde : le RAID (y compris RAIDZ) réduit le temps d’indisponibilité en cas de panne de disque mais ne protège pas contre les suppressions logiques, le ransomware ou « j’ai effacé le dataset ».

Modèle de menace : contre quoi vous vous défendez vraiment

Votre stratégie de sauvegarde devrait correspondre aux modes de défaillance, pas aux impressions. Voici ceux qui apparaissent réellement :

1) Le facteur humain (alias « c’est moi qui ai provoqué l’incident »)

Suppressions accidentelles, dataset détruit par erreur, nœud réinstallé à tort, disque effacé. Ce n’est pas un événement rare ; c’est une taxe récurrente.
Les snapshots sont excellents pour cela quand le pool est sain.

2) Perte du domaine de défaillance du stockage

Un HBA meurt et met plusieurs disques hors ligne, panne de backplane, bug de firmware, corruption du pool, ou simplement l’horreur au ralenti d’un pool qui n’importe plus après un reboot.
Si vos snapshots sont sur ce pool, ils font une jolie commémoration.

3) Ransomware et compromission des identifiants

Si un attaquant obtient le root de l’hyperviseur, il peut supprimer les snapshots. Il peut supprimer les sauvegardes locales. Il peut zfs destroy votre historique en une ligne.
Vous avez besoin d’immuabilité et de séparation des identifiants. C’est là que PBS brille, mais seulement si vous le déployez avec des frontières d’authentification sensées.

4) « Tout marche » jusqu’au jour où ça ne marche plus : incertitude sur la restauration

Les sauvegardes échouent silencieusement. Les restaurations échouent bruyamment. La seule sauvegarde qui compte est celle que vous avez restaurée récemment, idéalement dans un environnement de test isolé par réseau ressemblant à la production.

5) Régressions de performance qui transforment les sauvegardes en incident

Les sauvegardes peuvent détruire la latence, surtout pour des workloads I/O aléatoires petits blocs, des pools occupés, ou une rétention de snapshots agressive.
Il faut gérer quand les sauvegardes s’exécutent, ce qu’elles touchent, et avec quoi elles entrent en concurrence.

Comment Proxmox utilise ZFS (et pourquoi c’est important pour les sauvegardes)

Proxmox stocke généralement les disques de VM en tant que ZVOLs (périphériques blocs) lorsque vous sélectionnez un stockage ZFS. Les containers peuvent utiliser des datasets.
La distinction compte : les sauvegardes de ZVOL et de datasets se comportent différemment, surtout pour le snapshotting et l’utilisation d’espace.

VMs sur ZVOLs : snapshots rapides, espace compliqué

Un disque de VM en tant que ZVOL est un périphérique bloc avec un volblocksize (souvent 8K/16K). Les écritures proviennent du système de fichiers invité, pas des sémantiques ZFS.
Les snapshots préservent les anciens blocs ; une rétention longue peut créer une pression d’espace sérieuse sur des VMs à forte écriture (les bases de données adorent faire ça).

Containers sur datasets : plus de visibilité, mais pas magique

Les datasets peuvent être snapshotés et répliqués proprement, et ZFS peut faire de meilleurs choix de compression selon recordsize.
Mais les containers souffrent toujours du fait que « c’était sur le même pool », ce qui signifie que les snapshots ne vous sauvent pas d’une perte de pool.

Sauvegardes Proxmox : `vzdump` vs Proxmox Backup Server

vzdump crée des fichiers d’archive (.vma.zst, .tar.zst, etc.) sur une cible de stockage. Il peut utiliser des snapshots pour assurer la cohérence pendant la copie.
PBS stocke les sauvegardes en morceaux, déduplique entre VMs, et prend en charge le chiffrement et (optionnellement) des politiques de rétention qui ne consistent pas à « supprimer les vieux tarballs à la main ».

Les meilleurs déploiements utilisent souvent les deux concepts :
snapshots ZFS locaux pour rollback rapide et erreurs opérationnelles ;
PBS (ou une autre sauvegarde hors hôte) pour la vraie reprise après sinistre.

Snapshots : ce qu’ils font bien, ce qu’ils ne font absolument pas

Ils sont excellents pour :

Rollback rapide après des mises à jour de paquets ratées, des modifications de configuration VM cassées, ou un déploiement applicatif qui explose.
Filets de sécurité court terme lors d’opérations risquées : migrations, changements de système de fichiers, modifications de schéma.
Entrées pour réplication : les snapshots sont l’unité de transfert incrémental avec zfs send -i.

Ils ne sont pas adaptés pour :

Perte de pool : ils ne quittent pas le pool.
Compromission des identifiants : root peut les détruire.
Rétention longue sans planification de capacité : les anciens blocs retiennent de l’espace ; votre pool se remplit « mystérieusement ».
Récupération cohérente applicative : un snapshot cohérent après crash suffit souvent pour des systèmes de fichiers journaling, mais pas toujours pour des bases de données sans coordination.

La rétention de snapshots devrait être courte et intentionnelle. Des heures à des jours, peut‑être quelques semaines pour une fenêtre « oups » — selon le taux de changement.
Si vous conservez des mois de snapshots sur les pools de production, vous ne faites pas de « sauvegarde ». Vous faites « une fuite d’espace avec une API ».

Vraies sauvegardes : ce qui compte en production

Une vraie sauvegarde doit remplir trois conditions :

Séparation : stockée hors hôte ou au moins hors pool, idéalement hors site. Identifiants différents, rayon d’explosion différent.
Récupérabilité : vous pouvez restaurer dans un environnement propre, dans un RTO acceptable.
Vérification : vous avez effectué des restaurations tests récemment. Pas « vérifié les logs », pas « validé les checksums », mais réellement démarré ou vérifié l’intégrité des données.

Dans l’écosystème Proxmox, les implémentations de « vraie sauvegarde » les plus courantes sont :

Proxmox Backup Server : meilleur choix par défaut pour beaucoup d’équipes : déduplication, chiffrement, élagage, jobs de vérification.
vzdump vers NFS/SMB/une autre machine ZFS : simple et praticable, mais soyez honnête sur l’immuabilité et la vérification.
ZFS send/receive vers une cible de sauvegarde : puissant, transparent, rapide pour les incrémentaux ; facile aussi à mal configurer en miroir synchronisé d’un désastre.

« Les sauvegardes sans exercices de restauration » sont du théâtre de conformité. Et oui, le théâtre a des budgets.

Citation (idée paraphrasée) de W. Edwards Deming : Sans mesure, vous ne gérez pas — vous devinez. Les sauvegardes sont la mesure par la restauration.

Une conception de sauvegarde qui survit aux mauvais jours

Voici une stratégie qui fonctionne pour les petites équipes et évolue sans changer de nature :

Couche 1 : snapshots ZFS locaux pour rollback rapide

Gardez-les de courte durée.
Snapshot avant les changements risqués et selon un calendrier (par ex. horaire pendant 24h, quotidien pendant 7j).
Automatisez avec un outil de snapshots ou votre propre cron, mais gardez des noms cohérents.

Couche 2 : sauvegardes vers un système séparé (PBS recommandé)

PBS sur matériel séparé, idéalement un rack/domaine d’alimentation différent si possible.
Utilisez des identifiants séparés ; ne montez pas le datastore en RW depuis les hyperviseurs « juste parce que ».
Activez le chiffrement au moment de la sauvegarde si votre modèle de menace inclut le vol du stockage de sauvegarde.

Couche 3 : copie hors site (réplication ou synchronisation)

Soit sync PBS vers un second PBS, soit réplication ZFS vers une autre cible ZFS, soit export des sauvegardes vers un stockage objet via un pipeline contrôlé.
Assurez-vous que cette couche n’est pas un miroir de suppression. La réplication différée est une fonctionnalité, pas un défaut.

Rétention : arrêtez de faire comme si c’était un sentiment

La rétention est une décision politique basée sur :
les besoins réglementaires, la tolérance métier et les coûts de stockage.
Une base saine :

Snapshots locaux : 24–72 heures en horaire + 7–14 jours en quotidien (ajustez selon le taux d’écriture).
Sauvegardes PBS : 14–30 jours en quotidien + 3–12 mois en hebdo/mensuel, selon ce que l’entreprise appelle « oups ».
Hors site : au moins hebdomadaire, idéalement quotidien, avec rétention plus longue pour les fenêtres de récupération ransomware.

Cohérence : décidez de ce que vous entendez

Pour beaucoup de VMs, une cohérence crash-consistent suffit. Pour les bases de données, vous voulez, si possible, une cohérence applicative : flush, freeze, ou sauvegardes natives de la base.
ZFS ne sait pas ce qu’est « une transaction ». Il connaît des blocs.

Blague n°2 : « Nous répliquons instantanément vers le site DR » est la version sauvegarde de « je réponds toujours aux textos immédiatement ». C’est impressionnant jusqu’à ce que vous regrettiez ce que vous avez envoyé.

Tâches pratiques avec commandes : inspecter, décider, agir

Voici le type de tâches que vous exécutez lors de la mise en place, durant un incident, et lors du rituel mensuel « prouve que ça marche ».
Chaque tâche inclut : commande, sortie exemple, ce que cela signifie, et la décision à prendre.

Tâche 1 : Vérifier la santé du pool avant d’accuser les sauvegardes

cr0x@server:~$ zpool status -v
  pool: rpool
 state: ONLINE
  scan: scrub repaired 0B in 02:11:40 with 0 errors on Sun Dec 22 03:00:01 2025
config:

        NAME                        STATE     READ WRITE CKSUM
        rpool                       ONLINE       0     0     0
          mirror-0                  ONLINE       0     0     0
            ata-SAMSUNG_SSD_1       ONLINE       0     0     0
            ata-SAMSUNG_SSD_2       ONLINE       0     0     0

errors: No known data errors

Ce que cela signifie : Votre pool est sain, les scrubs se terminent, et il n’y a pas d’erreurs de checksum.
Décision : Ajustez snapshot/sauvegarde ; vous ne luttez pas contre une corruption sous-jacente du stockage.
Si vous voyez DEGRADED, FAULTED ou des erreurs de checksum, corrigez cela d’abord — churn de sauvegarde sur un pool malade aggrave souvent la situation.

Tâche 2 : Vérifier la capacité et si les snapshots verrouillent de l’espace

cr0x@server:~$ zfs list -o name,used,avail,refer,usedbysnapshots -r rpool/data
NAME                  USED  AVAIL  REFER  USEDBYSNAPSHOTS
rpool/data            3.2T   410G    96K            0B
rpool/data/vm-101     420G   410G   110G          210G
rpool/data/vm-102     610G   410G   240G          290G

Ce que cela signifie : Pour ces datasets ZVOL, une grosse partie de l’espace utilisé vient des « used by snapshots ». Ce sont d’anciens blocs retenus.
Décision : Resserrez la rétention des snapshots, ou déplacez la rétention longue vers PBS/hors hôte. Pensez si les VMs à fortes écritures devraient être sur leur propre pool ou suivre un calendrier différent.

Tâche 3 : Voir vos snapshots et vérifier que la nomenclature est sensée

cr0x@server:~$ zfs list -t snapshot -o name,creation,used -r rpool/data/vm-101 | tail -n 5
rpool/data/vm-101@auto-2025-12-27_0100  Sun Dec 27 01:00  1.2G
rpool/data/vm-101@auto-2025-12-27_0200  Sun Dec 27 02:00  1.0G
rpool/data/vm-101@auto-2025-12-27_0300  Sun Dec 27 03:00  980M
rpool/data/vm-101@auto-2025-12-27_0400  Sun Dec 27 04:00  1.1G
rpool/data/vm-101@pre-upgrade           Sat Dec 27 04:22  0B

Ce que cela signifie : Vous avez des snapshots réguliers plus un snapshot manuel « pre-upgrade ». Bien.
Décision : Assurez-vous que la rétention correspond à l’intention. La colonne « used » qui augmente lentement est normale ; des pics soudains indiquent de gros changements (mises à jour invitées, forte activité DB).

Tâche 4 : Identifier rapidement les pires consommateurs de snapshots

cr0x@server:~$ zfs list -o name,usedbysnapshots -s usedbysnapshots -r rpool/data | tail -n 5
rpool/data/vm-215     180G
rpool/data/vm-102     290G
rpool/data/vm-101     210G
rpool/data/vm-330     340G
rpool/data/vm-407     390G

Ce que cela signifie : Ces datasets verrouillent le plus d’espace par les snapshots.
Décision : Passez en revue la rétention et l’approche de sauvegarde pour ces VMs en priorité. Si vous avez besoin d’un historique long, ne le conservez pas sur le pool primaire.

Tâche 5 : Confirmer les propriétés ZVOL qui affectent sauvegarde/réplication

cr0x@server:~$ zfs get -o name,property,value -s local,default volblocksize,compression,recordsize rpool/data/vm-101
NAME               PROPERTY      VALUE
rpool/data/vm-101   volblocksize  16K
rpool/data/vm-101   compression   zstd

Ce que cela signifie : Le ZVOL utilise un volblocksize de 16K, compression activée. Recordsize ne s’applique pas aux ZVOLs.
Décision : Ne changez pas volblocksize au hasard après la provision sauf si vous comprenez les conséquences. La compression est généralement bonne ; mesurez CPU et latence si vous êtes proche des limites.

Tâche 6 : Vérifier le calendrier et les résultats des scrubs

cr0x@server:~$ zpool get scrubtime rpool
NAME   PROPERTY  VALUE                  SOURCE
rpool  scrubtime Sun Dec 22 03:00 2025  -

Ce que cela signifie : Le dernier scrub est enregistré. Les scrubs détectent les erreurs latentes avant qu’un rebuild ou une restauration n’ait besoin de ces blocs.
Décision : Si vous ne faites pas de scrubs mensuels (ou plus souvent pour de grands/anciens disques), programmez-les. Si les scrubs échouent ou ne se terminent jamais, sonnez l’alarme.

Tâche 7 : Vérifier la pression ARC avant d’accuser une « lenteur de sauvegarde »

cr0x@server:~$ arc_summary | egrep "ARC Size|ARC Target|Cache Hits|Cache Misses"
ARC Size:                               31.2 GiB
ARC Target Size:                        32.0 GiB
Cache Hits:                             92.1%
Cache Misses:                           7.9%

Ce que cela signifie : L’ARC est proche de sa cible et le taux de hit est sain.
Décision : Votre pool n’est pas manifestement à court de mémoire. Si le taux de hit est bas et que les misses sont élevés pendant les sauvegardes, envisagez de planifier, limiter la concurrence, ou d’augmenter la mémoire — surtout sur des nœuds hyperviseur+stockage tout-en-un.

Tâche 8 : Surveiller la latence I/O pendant les sauvegardes

cr0x@server:~$ zpool iostat -v rpool 5 3
                              capacity     operations     bandwidth
pool                        alloc   free   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----
rpool                        3.1T   410G    820   1600   110M   220M
  mirror-0                   3.1T   410G    820   1600   110M   220M
    ata-SAMSUNG_SSD_1           -      -    410    800    55M   110M
    ata-SAMSUNG_SSD_2           -      -    410    800    55M   110M
--------------------------  -----  -----  -----  -----  -----  -----

Ce que cela signifie : Vous observez des écritures soutenues pendant les sauvegardes. C’est normal, mais l’important est de savoir si la latence des invités augmente.
Décision : Si vos VMs se plaignent durant cette fenêtre, déplacez les sauvegardes, réduisez la concurrence, ou ajoutez une cible de sauvegarde séparée pour éviter de frapper le pool principal.

Tâche 9 : Confirmer les définitions de stockage Proxmox (et éviter de sauvegarder « local » par erreur)

cr0x@server:~$ pvesm status
Name             Type     Status     Total     Used     Available        %
local             dir     active      94G      12G         82G       12.8%
local-zfs         zfspool active     3.5T     3.1T        410G       88.3%
pbs-prod          pbs     active      18T      6.2T       11.8T      34.4%

Ce que cela signifie : Vous avez un datastore PBS disponible. Bien. Le stockage local dir n’est pas une destination de sauvegarde sauf s’il est sur du matériel séparé (ce n’est généralement pas le cas).
Décision : Assurez-vous que les jobs planifiés ciblent pbs-prod, pas local ou local-zfs.

Tâche 10 : Inspecter les jobs de sauvegarde et leurs cibles

cr0x@server:~$ cat /etc/pve/jobs.cfg | sed -n '1,120p'
backup: nightly-pbs
        enabled 1
        schedule 03:15
        storage pbs-prod
        mode snapshot
        compress zstd
        mailnotification always
        prune-backups keep-daily=14,keep-weekly=8,keep-monthly=6

Ce que cela signifie : Les sauvegardes nocturnes vont vers PBS, avec élagage défini.
Décision : Si l’élagage manque, ajoutez-le. Si l’horaire chevauche scrub, réplication, ou charge de pointe, déplacez-le.

Tâche 11 : Lancer un vzdump manuel pour une VM et lire le résultat

cr0x@server:~$ vzdump 101 --storage pbs-prod --mode snapshot --compress zstd --notes-template '{{vmid}} {{name}}'
INFO: starting new backup job: vzdump 101 --storage pbs-prod --mode snapshot --compress zstd
INFO: Starting Backup of VM 101 (qemu)
INFO: Backup started at 2025-12-28 03:22:11
INFO: status = running
INFO: VM Name: app-prod-01
INFO: including disk 'scsi0' 'local-zfs:vm-101-disk-0' 110G
INFO: creating Proxmox Backup Server archive 'vm/101/2025-12-28T03:22:11Z'
INFO: transferred 33.1 GiB in 04:18 min, average speed 131.2 MiB/s
INFO: backup successful
INFO: Backup finished at 2025-12-28 03:26:30
INFO: Finished Backup of VM 101 (00:04:19)

Ce que cela signifie : Le succès n’est pas seulement « code de sortie 0 » ; c’est « archive créée sur PBS » avec un débit et une durée plausibles.
Décision : Si la vitesse est anormalement basse, vérifiez zpool iostat, le réseau et la charge PBS. Si ça dit qu’il a sauvegardé localement, corrigez la cible immédiatement.

Tâche 12 : Vérifier la santé du datastore PBS depuis le nœud Proxmox (atteignabilité + authentification)

cr0x@server:~$ pvesm list pbs-prod | head
Volid                                                        Format  Type         Size  VMID
pbs-prod:backup/vm/101/2025-12-28T03:22:11Z                   pbs     backup   35567616   101
pbs-prod:backup/vm/102/2025-12-28T03:15:01Z                   pbs     backup   74448896   102
pbs-prod:backup/vm/215/2025-12-28T03:18:45Z                   pbs     backup   118382592  215

Ce que cela signifie : Le nœud peut lister les sauvegardes sur PBS. Cela valide la config de stockage et l’authentification à un niveau basique.
Décision : Si la liste échoue de façon intermittente, enquêtez sur la fiabilité réseau et la santé du service PBS avant de faire confiance aux jobs nocturnes.

Tâche 13 : Vérifier la sanity de la réplication ZFS (si vous utilisez send/receive)

cr0x@server:~$ zfs send -nP rpool/data/vm-101@auto-2025-12-27_0400 | head
size	11811160064

Ce que cela signifie : Le dry-run montre la taille du stream. C’est ainsi que vous prévoyez le temps et la bande passante de réplication.
Décision : Si la taille est énorme pour un « petit changement », vous ne faites peut-être pas d’envois incrémentaux, ou la VM churn beaucoup de blocs. Ajustez l’horaire et la rétention, ou passez à PBS pour l’efficience de déduplication.

Tâche 14 : Confirmer que vous pouvez réellement recevoir sur la cible (et que vous n’écrasez pas la production)

cr0x@server:~$ ssh root@backupzfs "zfs list -o name,used,avail -r bpool/replica | head"
NAME                 USED  AVAIL
bpool/replica        1.1T  7.8T
bpool/replica/rpool  1.1T  7.8T

Ce que cela signifie : La cible a un dataset/pool de réplica dédié. C’est de l’hygiène basique.
Décision : Si vous recevez dans un pool au nom similaire sans séparation, vous êtes à un bug de script d’un envoi destructeur dans les deux sens.

Tâche 15 : Faire une restauration test d’une VM dans un ID isolé (le seul test qui compte)

cr0x@server:~$ qmrestore pbs-prod:backup/vm/101/2025-12-28T03:22:11Z 9101 --storage local-zfs
restore vma archive: vm/101/2025-12-28T03:22:11Z
creating VM 9101 on target node
  restoring disk scsi0 size 110G to local-zfs:vm-9101-disk-0
progress 15% (read 5.0 GiB, write 5.0 GiB)
progress 62% (read 21.0 GiB, write 21.0 GiB)
progress 100% (read 33.1 GiB, write 33.1 GiB)
restore successful

Ce que cela signifie : Vous pouvez restaurer. Pas « en théorie », pas « les logs sont verts », mais création réelle de VM et matérialisation du disque.
Décision : Démarrez-la sur un réseau isolé, validez la santé de l’application, puis détruisez-la. Programmez cela mensuellement au minimum pour les services critiques.

Tâche 16 : Vérifier la corrélation charge snapshot/sauvegarde et latence VM (vue rapide)

cr0x@server:~$ iostat -x 5 3
Linux 6.8.12 (server)   12/28/2025

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          12.10    0.00    6.55    8.40    0.00   72.95

Device            r/s     w/s   rkB/s   wkB/s  await  svctm  %util
nvme0n1         220.0  1400.0  95000  210000   9.80   0.35  58.00

Ce que cela signifie : %iowait élevé et await montrent que le système attend le stockage. Pendant les sauvegardes, c’est attendu ; un await soutenu corrèle avec la lenteur des VMs.
Décision : Si await monte à des dizaines/centaines de ms, réduisez la concurrence des sauvegardes, changez l’horaire, ou séparez l’I/O de sauvegarde du stockage de production.

Procédure de diagnostic rapide

Quand les sauvegardes ralentissent, échouent, ou « réussissent » mais que les restaurations sont pénibles, vous ne voulez pas un séminaire philosophique. Vous voulez une séquence.

Première étape : confirmez que vous sauvegardez au bon endroit

Vérifiez la config du job Proxmox : cible de stockage, mode, élagage.
Confirmez que la destination est accessible et a de l’espace libre.

Deuxième étape : identifiez le domaine de goulot d’étranglement (disque, CPU, réseau, PBS)

Latence disque : zpool iostat, iostat -x
Pression CPU : top et « la compression monopolise-t-elle les cœurs ? »
Réseau : ip -s link, ss -s, ou les compteurs du switch
Charge PBS : jobs de vérification, garbage collection, clients concurrents

Troisième étape : vérifiez la pression des snapshots et la capacité du pool

zfs list -o usedbysnapshots pour trouver l’espace bloqué.
zpool list pour la capacité globale ; évitez de vivre au‑dessus de ~80–85% sur les pools chargés.

Quatrième étape : validez les mécanismes de restauration

Choisissez une VM et faites une restauration test sur un VMID temporaire.
Si la restauration est lente, le même goulot existe probablement, mais en lecture depuis la cible de sauvegarde.

Cinquième étape : réduisez la concurrence avant de refondre le monde

Beaucoup d’« incidents » de sauvegarde Proxmox sont auto-infligés en lançant trop de sauvegardes en parallèle.
La concurrence est un réglage. Utilisez-le.

Erreurs courantes : symptôme → cause racine → correction

1) « Nous avons des snapshots, donc nous sommes sauvegardés. »

Symptôme : Le pool n’importe pas, et tout — disques VM et snapshots — est inaccessible.

Cause racine : Les snapshots n’ont jamais quitté le domaine de défaillance du pool.

Correction : Mettez en place PBS ou une réplication ZFS hors hôte. Exigez des restaurations tests mensuelles comme condition pour appeler quelque chose « sauvegardé ».

2) Les jobs de sauvegarde sont verts, mais les restaurations échouent

Symptôme : Vous voyez des entrées de sauvegarde, mais des erreurs de restauration surviennent (morceaux manquants, échecs d’auth, archives corrompues).

Cause racine : Pas d’exercices de restauration ; les problèmes s’accumulent silencieusement (permissions, erreurs d’élagage du datastore, réseau intermittent).

Correction : Ajoutez des restaurations test programmées. Pour PBS, lancez des jobs de vérification et surveillez les taux d’échec. Corrigez les frontières d’authentification et la fragilité réseau.

3) Le pool ZFS se remplit de façon inattendue

Symptôme : df montre beaucoup d’espace quelque part, mais ZFS rapporte peu d’AVAIL. Les écritures VM commencent à échouer.

Cause racine : La rétention des snapshots verrouille des blocs ; les VMs à fort churn gardent les anciens blocs vivants. Commun aussi : fonctionner à 90%+ d’utilisation du pool.

Correction : Réduisez la rétention des snapshots. Déplacez la rétention longue vers PBS. Gardez les pools en dessous de ~80–85% pour la performance et le contrôle de la fragmentation.

4) La réplication « fonctionne » puis vous réalisez qu’elle a répliqué le désastre

Symptôme : Une suppression ou un chiffrement par ransomware apparaît rapidement sur la réplique.

Cause racine : Réplication continue sans points de contrôle différés ; la réplique est traitée comme un miroir, pas comme une sauvegarde.

Correction : Utilisez une réplication différée, conservez l’historique de snapshots sur la réplique, et protégez la réplique des identifiants de production. Pour le ransomware, l’immuabilité compte.

5) Les sauvegardes provoquent des pics de latence VM

Symptôme : Timeouts applicatifs pendant la fenêtre de sauvegarde ; graphiques de latence de stockage en pic.

Cause racine : Jobs de sauvegarde en concurrence pour les IOPS et le cache ; trop de VMs concurrentes ; scrubs/resilver simultanés.

Correction : Changez l’horaire, réduisez la concurrence, déplacez les sauvegardes hors hôte, séparez les pools, ou ajoutez des médias plus rapides pour la charge chaude.

6) « Nous avons chiffré le pool donc les sauvegardes sont sûres »

Symptôme : La cible de sauvegarde est non chiffrée, ou les clés sont stockées sur le même hyperviseur.

Cause racine : Confusion entre chiffrement au repos et contrôles d’accès opérationnels ; la gestion des clés traitée en dernier.

Correction : Chiffrez les sauvegardes au moment de la sauvegarde (PBS le permet). Stockez les clés séparément. Limitez qui peut supprimer les sauvegardes et comment.

Trois mini-récits d’entreprise venus du terrain

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

Une entreprise de taille moyenne exécutait Proxmox sur un hôte costaud avec des SSD en miroir. Ils avaient des snapshots ZFS horaires pendant deux semaines.
L’équipe croyait être « couverte », car les rollbacks les avaient sauvés plusieurs fois après des déploiements applicatifs ratés.

Puis vint un redémarrage imprévu après un événement d’alimentation. Le pool ne s’est pas importé proprement. Ils avaient un environnement de démarrage, des snapshots,
et de la confiance. Ce qu’ils n’avaient pas, c’était une seconde copie des disques VM ailleurs.

La récupération devint un projet d’archéologie du stockage : tentatives d’import avec différents flags, vérifications matérielles, et une peur croissante que la « réparation » aggrave le dommage.
Finalement, ils récupérèrent la plupart des données, mais cela prit assez longtemps pour que l’entreprise commence à prendre des décisions opérationnelles sur base d’un service partiel.

Le postmortem fut inconfortable parce que la « mauvaise hypothèse » n’était pas technique ; elle était sémantique. Ils appelaient les snapshots « sauvegardes ».
Une fois le langage corrigé, l’architecture suivit. PBS fut déployé sur du matériel séparé, les tests de restauration devinrent des tickets récurrents, et les snapshots furent rétrogradés à ce qu’ils sont : des filets locaux.

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

Un autre service estima que les sauvegardes étaient trop lentes, alors ils ont poursuivi le débit. Ils augmentèrent la concurrence des sauvegardes et réglèrent la compression au maximum.
La fenêtre de sauvegarde rétrécit. Les graphs étaient beaux. Tout le monde se félicita.

Deux semaines plus tard, les utilisateurs se plaignirent de pics de latence aléatoires tôt le matin. Rien d’évident n’était « down », mais tout semblait collant.
L’équipe inspecta le CPU — ok. Le réseau — ok. Puis la latence stockage : moche.

L’optimisation avait transformé les sauvegardes en une tempête de lectures/écritures aléatoires soutenues au moment où des jobs batch lourds tournaient aussi dans les invités.
ZFS faisait son travail, mais le pool était fragmenté et fortement utilisé. Les sauvegardes concouraient avec la production, et la production perdit.

La correction fut ennuyeuse : réduire la concurrence, déplacer les VMs les plus lourdes vers une autre fenêtre, et arrêter de traiter le débit de sauvegarde comme le seul KPI.
Ils ajoutèrent aussi une règle : si un changement améliore la vitesse de sauvegarde mais augmente la latence p95 de la production, ce n’est pas une optimisation. C’est un compromis que vous n’aviez pas chiffré.

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

Une équipe de services financiers avait l’habitude qui ressemblait à de la paperasserie : chaque mois, un ingénieur restaurait deux VMs critiques depuis PBS sur un réseau isolé.
Ils vérifiaient les checks de santé du service, se connectaient à l’application, puis détruisaient les VMs de test. Cela prenait une heure et ne produisait aucun dashboard excitant.

Un jour, une mise à jour d’hyperviseur tourna mal. Le nœud ne démarra pas, et l’import du pool local était instable. Ce n’était pas une perte totale, mais ce n’était pas fiable.
L’équipe prit une décision rapidement : arrêter de tripoter l’hôte cassé, restaurer sur un autre nœud, et remettre les services en ligne proprement.

Le plan de restauration fonctionna parce qu’ils l’avaient répété. Ils savaient déjà quelles sauvegardes étaient les plus rapides à restaurer, quels réseaux attacher, et quels identifiants étaient nécessaires.
Leur panne se mesura en quelques heures, pas en jours de « peut‑être on peut réparer le pool ».

Le comble : le rituel mensuel de restauration avait été précédemment qualifié de « perte de temps ».
Après coup, plus personne ne le remis en question. L’ennui est une fonctionnalité quand l’immeuble brûle.

Listes de contrôle / plan étape par étape

Étape par étape : construire une stratégie de sauvegarde qui ne ment pas

Définissez RPO/RTO par service. Si vous ne pouvez pas dire « nous pouvons perdre X heures et être indisponibles Y heures », vous ne pouvez pas choisir les outils honnêtement.
Gardez les snapshots locaux courts. Utilisez-les pour rollback, pas pour l’historique.
Déployez PBS sur du matériel séparé. Disques différents, alimentation différente si possible. Identifiants séparés.
Planifiez les sauvegardes hors des pics I/O. Évitez les chevauchements avec scrubs, resilvers, jobs batch lourds.
Définissez la rétention dans le système de sauvegarde. Élagage sur PBS (ou équivalent) pour que la rétention soit applicable et visible.
Activez le chiffrement là où c’est pertinent. Surtout si les sauvegardes sont hors site ou accessibles par de nombreux systèmes.
Faites des exercices de restauration mensuels. Restaurez une VM sur un nouveau VMID, démarrez-la, validez, puis supprimez-la.
Surveillez les signaux ennuyeux. Capacité du pool, fin des scrubs, durée des jobs de sauvegarde, durée des restaurations, échecs de vérification.
Documentez le runbook de restauration. Où vivent les sauvegardes, qui a accès, comment restaurer le réseau, quel ordre pour restaurer les dépendances.

Checklist : avant de faire confiance à votre installation

Sauvegardes stockées hors hôte et hors pool
Identifiants séparés pour supprimer les sauvegardes
Rétention et élagage configurés
Au moins une restauration test réussie dans les 30 derniers jours
Scrubs ZFS programmés et complétés
Capacité du pool sous contrôle (ne pas vivre à 90% plein)
Fenêtres de sauvegarde qui ne nuisent pas à la latence de production

Checklist : quand vous changez quelque chose de risqué

Prendre un snapshot manuel avec un nom humain (@pre-upgrade)
Confirmer qu’une dernière sauvegarde PBS réussie existe pour les VMs critiques
Vérifier que vous pouvez atteindre la cible de sauvegarde maintenant
Avoir un plan de rollback et un plan de restauration — ce sont deux plans différents

FAQ

1) Les snapshots ZFS suffisent-ils parfois comme sauvegardes ?

Seulement si votre définition de « sauvegarde » exclut la perte matérielle, la corruption du pool et la compromission root — définition principalement utilisée par les vendeurs d’optimisme.
Pour des environnements réels : non.

2) Si je réplique les snapshots ZFS vers un autre hôte, est-ce une sauvegarde ?

Ça peut l’être si la cible est indépendante et protégée. Mais la réplication réplique souvent les erreurs rapidement.
Faites la réplication différée, conservez l’historique sur la cible, et utilisez des identifiants séparés pour que le root production ne puisse pas détruire la réplique.

3) Dois‑je utiliser Proxmox Backup Server ou vzdump vers NFS ?

PBS est le meilleur choix par défaut : déduplication, chiffrement, vérification, élagage. NFS peut fonctionner, mais vous devez concevoir vous‑même l’immuabilité et la vérification,
et vous en paierez probablement le prix opérationnel plus tard.

4) Ai‑je besoin à la fois de snapshots et de sauvegardes ?

En pratique, oui. Les snapshots servent au rollback rapide et à la gestion du changement. Les sauvegardes servent à la reprise après sinistre et à la rétention audit‑grade.
Forcer l’un à faire le travail de l’autre mène généralement à de la douleur.

5) Combien de snapshots devrais‑je garder sur le pool de production ?

Gardez le minimum nécessaire pour vos besoins de rollback. Pour beaucoup d’environnements : horaire pendant 24–72 heures et quotidien pendant 7–14 jours.
Si vous avez besoin de mois, gardez‑les hors hôte dans le système de sauvegarde.

6) Mon pool est à 90% mais « ça marche encore ». Pourquoi insister ?

Parce que la performance et le comportement d’allocation de ZFS se dégradent à mesure que l’espace libre diminue, surtout sur des pools occupés. Les snapshots rendent aussi le « libre » trompeur.
Vous ne voulez pas découvrir la falaise pendant un incident quand vous avez besoin d’écritures pour restaurer.

7) Comment rendre les sauvegardes résilientes au ransomware ?

Utilisez la séparation des identifiants, l’immuabilité (là où disponible), des copies différées/hors ligne, et un système de sauvegarde qui ne peut pas être supprimé par des hyperviseurs compromis.
Aussi : des exercices de restauration, car la récupération ransomware est surtout « à quelle vitesse pouvons‑nous restaurer proprement ».

8) Les scrubs ZFS remplacent‑ils les sauvegardes ?

Non. Les scrubs détectent et réparent la corruption en utilisant la redondance. Ils ne protègent pas contre la suppression, le chiffrement ou la perte catastrophique du pool.
Les scrubs aident à garantir que, quand vous avez besoin de vos données, elles se lisent correctement.

9) Quel est le métrique le plus important pour les sauvegardes ?

Le temps de restauration pour une charge représentative. Pas la durée de la sauvegarde, pas le taux de déduplication. L’entreprise ressent le temps de restauration.

10) Que faire si les sauvegardes ralentissent avec le temps ?

Vérifiez la capacité (y compris le verrouillage par snapshots), vérifiez la latence pendant la fenêtre de sauvegarde, et vérifiez la concurrence. Puis vérifiez la santé de la cible de sauvegarde.
Les sauvegardes lentes sont souvent le symptôme de « pool trop plein » ou « trop de jobs en même temps », pas une malédiction mystique.

Conclusion : prochaines étapes rentables

Arrêtez d’appeler les snapshots des sauvegardes. Élevez‑les au rang d’« outils de rollback », et vous prendrez immédiatement de meilleures décisions sur la rétention, la capacité et le risque.
Ensuite, construisez de vraies sauvegardes qui quittent le domaine de défaillance, sont protégées contre la suppression facile, et sont prouvées par des restaurations.

Prochaines étapes pratiques :

Choisissez une VM critique et effectuez une restauration test depuis votre système de sauvegarde cette semaine. Chronométrez‑la. Écrivez les étapes.
Auditez où atterrissent vos sauvegardes. Si quelque chose indique « local » sur le même hôte, considérez‑le comme de la commodité, pas de la protection.
Mesurez l’espace verrouillé par les snapshots et réduisez la rétention sur les plus gros consommateurs.
Planifiez des scrubs et assurez‑vous qu’ils se terminent.
Mettez en place des sauvegardes hors hôte (PBS recommandé) avec élagage et vérification, et des identifiants séparés pour la suppression.

Quand le mauvais jour arrivera — et il arrivera — vous voulez que votre stratégie de sauvegarde soit ennuyeuse, répétable et un peu suffisante. Pas parce que vous aimez l’autosatisfaction,
mais parce que vos utilisateurs aiment le service.