9. Sauvegardes locales avec vzdump

9.1 La sauvegarde vzdump — fonctionnement

vzdump est l'outil de sauvegarde intégré à Proxmox. Il crée une archive complète d'une VM (configuration + disque) sous forme d'un fichier .vma.zst (VM Archive, compressé).

Cette archive peut être restaurée sur n'importe quel Proxmox compatible. Trois modes existent — stop, suspend et snapshot — détaillés au §9.2 ; le mode snapshot est le plus utilisé en production, parce que la VM continue de tourner pendant la sauvegarde.

Via l'interface graphique :

VM → Backup → Backup Now

Champ	Valeur
Storage	`local`
Mode	`Snapshot`
Compression	`ZSTD`
Note	`sauvegarde avant migration`

9.2 Créer et restaurer une sauvegarde

Le bouton Backup Now lance vzdump ; la commande s'utilise aussi directement, pour une sauvegarde ponctuelle ou scriptée, et qmrestore restaure depuis une archive existante.

Le paramètre décisif est le mode, parce qu'il arbitre entre cohérence des données et disponibilité de la VM :

Mode	Ce qu'il fait	Contrepartie
`snapshot`	Sauvegarde à chaud, VM allumée, via un instantané du disque	Cohérence au niveau bloc seulement — d'où l'intérêt de l'agent invité
`suspend`	Fige la VM le temps de la sauvegarde	Interruption de service pendant la copie
`stop`	Arrête la VM, sauvegarde, redémarre	Cohérence parfaite, mais coupure franche

En pratique on emploie snapshot presque partout, et c'est là que l'agent invité QEMU prend tout son sens. Au moment du snapshot, Proxmox lui demande de geler le système de fichiers de la VM (fsfreeze), le temps de figer le disque. Sans agent, le snapshot capture un disque dans l'état d'une coupure de courant — récupérable, mais pas garanti cohérent pour une base de données en pleine écriture.

Avec agent, la sauvegarde est propre. C'est la raison de fond pour laquelle on installe systématiquement qemu-guest-agent dans les VMs.

Ce que vit la VM pendant la sauvegarde, selon le mode. En snapshot, elle reste en service et l'agent invité ne gèle le système de fichiers qu'un instant. En suspend, elle est figée tout du long.

En stop, elle est éteinte puis redémarrée. Cliquez sur un mode pour le détail.

Une restauration écrase, elle ne fusionne pas. qmrestore sur un VMID existant remplace intégralement la VM par le contenu de l'archive — tout ce qui a été écrit depuis la sauvegarde est perdu. Restaurer vers un nouveau VMID est la précaution qui permet de comparer avant de remplacer, et c'est la pratique à enseigner.

Dans le Shell du nœud (interface web → votre nœud → Shell) :

# Sauvegarder la VM 100 en mode snapshot avec compression ZSTD
vzdump 100 --storage local --mode snapshot --compress zstd

# Sauvegarder toutes les VMs d'un nœud
vzdump --all --storage local --mode snapshot --compress zstd

# Lister les sauvegardes disponibles dans le stockage local
pvesm list local --content backup

# Restaurer depuis une archive (crée une nouvelle VM)
qmrestore /var/lib/vz/dump/vzdump-qemu-100-2026_09_29-13_51_54.vma.zst 199 \
  --storage local-lvm --unique 1

# Restaurer vers la même VM ID (VM doit être éteinte ou inexistante)
qmrestore /var/lib/vz/dump/vzdump-qemu-100-2026_09_29-13_51_54.vma.zst 100 \
  --storage local-lvm --force 1

Résultat attendu de vzdump, sur la VM 101 du lab (même commande, avec 101 à la place de 100) :

INFO: starting new backup job: vzdump 101 --compress zstd --mode snapshot --storage local
INFO: Starting Backup of VM 101 (qemu)
INFO: Backup started at 2026-09-29 13:51:54
INFO: status = running
INFO: VM Name: vm-web-01
INFO: include disk 'scsi0' 'local-lvm:vm-101-disk-0' 20G
INFO: backup mode: snapshot
INFO: ionice priority: 7
INFO: snapshots found (not included into backup)
INFO: creating vzdump archive '/var/lib/vz/dump/vzdump-qemu-101-2026_09_29-13_51_54.vma.zst'
INFO: issuing guest-agent 'fs-freeze' command
INFO: starting backup via QMP command
INFO: issuing guest-agent 'fs-thaw' command
INFO: started backup task '4bd7ddcc-f7ae-4933-8d0d-b04e2c47b046'
INFO: resuming VM again
INFO:   9% (1.9 GiB of 20.0 GiB) in 3s, read: 638.0 MiB/s, write: 358.1 MiB/s
INFO: 100% (20.0 GiB of 20.0 GiB) in 5s, read: 9.1 GiB/s, write: 22.6 MiB/s
INFO: backup is sparse: 18.91 GiB (94%) total zero data
INFO: transferred 20.00 GiB in 5 seconds (4.0 GiB/s)
INFO: archive file size: 402MB
INFO: Finished Backup of VM 101 (00:00:06)
INFO: Backup finished at 2026-09-29 13:52:00
INFO: Backup job finished successfully
INFO: notified via target `mail-to-root`

L'archive est créée dans /var/lib/vz/dump/ ; son nom inclut le VMID, la date et l'heure. Cinq lignes de ce journal méritent qu'on s'y arrête.

Ligne	Ce qu'elle dit
`fs-freeze` puis `fs-thaw`	L'agent invité a gelé puis dégelé les systèmes de fichiers de la VM le temps de poser le snapshot. Sans agent, ces deux lignes manquent, et la sauvegarde n'a que la cohérence d'une coupure de courant
`snapshots found (not included into backup)`	La VM a des snapshots : ils ne sont pas sauvegardés. L'archive contient l'état présent de la VM, rien d'autre
`backup is sparse: 18.91 GiB (94%) total zero data`	94 % du disque n'a jamais été écrit, et vzdump ne stocke pas ces zéros
`archive file size: 402MB`	La taille réelle, après compression zstd, pour un disque de 20 Go. C'est ce rapport qu'il faut surveiller pour dimensionner le stockage des sauvegardes
`notified via target mail-to-root`	Le résultat part vers la cible de notification par défaut, `mail-to-root` (le courrier local de root)

Planification automatique : dans l'interface, Datacenter → Backup → Add permet de créer des jobs planifiés (CRON : déclenchement à heures fixes). En production, on planifie des sauvegardes nocturnes avec une rétention configurable (garder les 7 derniers jours, par exemple).

9.3 Rétention automatique des sauvegardes

Sauvegarder chaque nuit sans jamais purger les anciennes archives conduit inévitablement à saturer le stockage de sauvegarde. Proxmox intègre un mécanisme de rétention basé sur des règles de type grand-père/père/fils, comme la plupart des outils de sauvegarde professionnels. Il conserve un nombre défini de sauvegardes quotidiennes, hebdomadaires, mensuelles et annuelles, et purge automatiquement le reste.

Dans le Shell du nœud (interface web → votre nœud → Shell) :

# Sauvegarder avec rétention : 7 quotidiennes, 4 hebdomadaires, 6 mensuelles
vzdump 100 --storage local --mode snapshot --compress zstd \
  --prune-backups keep-daily=7,keep-weekly=4,keep-monthly=6

# Appliquer une politique de rétention à des sauvegardes déjà existantes
# (sans en créer de nouvelle) : d'abord à blanc, pour voir ce qui partirait
pvesm prune-backups local --vmid 100 --keep-daily 7 --keep-weekly 4 --dry-run 1
pvesm prune-backups local --vmid 100 --keep-daily 7 --keep-weekly 4   # puis pour de vrai

Résultat attendu de la sauvegarde avec rétention (extrait) :

INFO: Finished Backup of VM 100 (00:00:12)
INFO: prune older backups with retention: keep-daily=7, keep-monthly=6, keep-weekly=4
INFO: removing backup 'local:backup/vzdump-qemu-100-2026_05_10-02_00_00.vma.zst'
INFO: pruned 3 backup(s) not covered by keep-retention policy

Le passage --dry-run 1 de pvesm prune-backups affiche, pour chaque archive, keep ou remove et la règle qui la retient. C'est la seule façon de vérifier une politique avant qu'elle n'efface quoi que ce soit.

Proxmox conserve les sauvegardes les plus pertinentes selon la politique définie, et supprime automatiquement les archives devenues redondantes. Par exemple, une sauvegarde quotidienne de plus de 7 jours n'est conservée que si elle correspond aussi à une échéance hebdomadaire ou mensuelle encore active.

Ces mêmes options de rétention sont configurables graphiquement dans Datacenter → Backup → Add, sous la section Retention, au moment de planifier un job de sauvegarde récurrent. En production, définissez cette politique dès la création du job plutôt que de laisser les sauvegardes s'accumuler sans limite. Un stockage de sauvegarde saturé fait systématiquement échouer la sauvegarde suivante, généralement au pire moment.

À retenir : vzdump produit une archive complète de la VM ; le mode (snapshot, suspend, stop) arbitre entre continuité de service et cohérence. qmrestore écrase la VM cible. Une rétention (keep-daily, keep-weekly…) évite de saturer le stockage.

▶ À pratiquer maintenant — Atelier 6

Prendre un instantané, casser puis revenir en arrière ; sauvegarder la VM, puis la restaurer sous un nouveau numéro sans conflit d'adresse.