Chapitre 915 minIntermédiaire
Snapshot et sauvegarde de VM : vzdump et Proxmox Backup Server
Par Josselyn C., prof de BTS SIO. Mis à jour le .
À la fin de ce chapitre, tu sauras
- prendre, utiliser et supprimer un snapshot au bon moment ;
- expliquer pourquoi un snapshot n'est pas une sauvegarde ;
- sauvegarder et restaurer une VM avec
vzdump; - relier Proxmox VE à Proxmox Backup Server et protéger la clé de chiffrement.
4 exercices corrigés1 schéma
Un snapshot (instantané) fige l'état d'une machine virtuelle à un instant donné, sur le même stockage qu'elle, pour pouvoir y revenir en quelques secondes ; une sauvegarde est une copie complète de la VM, rangée ailleurs, qui permet de la reconstruire même si son hôte et son stockage ont disparu. Ce chapitre explique le fonctionnement des snapshots et leurs règles d'usage, pourquoi un snapshot n'est pas une sauvegarde, puis les sauvegardes de Proxmox VE avec vzdump et avec Proxmox Backup Server.
Comment fonctionne un snapshot
Au moment du snapshot, le stockage fige les blocs du disque de la VM. Les écritures suivantes ne modifient plus ces blocs : elles vont ailleurs (c'est la copie sur écriture, copy-on-write), et le stockage garde la trace de ce qui a changé depuis. Revenir au snapshot (rollback), c'est jeter les changements et repartir des blocs figés. C'est pour cela qu'un snapshot est instantané et prend peu de place au début : il ne copie rien, il arrête juste d'écraser.
Un snapshot de VM sous Proxmox enregistre :
- l'état de tous les disques de la VM ;
- sa configuration (mémoire, processeurs, cartes) à ce moment-là ;
- si tu coches Include RAM, le contenu de sa mémoire : en revenant au snapshot, la VM repart exactement où elle en était, programmes ouverts. Sans la mémoire, elle repart comme après une coupure de courant, d'où l'intérêt de l'agent invité, qui fige les systèmes de fichiers au moment du snapshot.
Le snapshot n'est possible que si le stockage le permet : LVM-thin, ZFS, Ceph, ou un disque qcow2 sur un dossier ou un partage NFS (chapitre 4).
Prendre et utiliser un snapshot
Dans l'interface, sélectionne la VM, onglet Snapshots, puis Take Snapshot : un nom sans espace (avant-maj-glpi), Include RAM si besoin, une description. Les boutons Rollback et Remove reviennent au snapshot et le suppriment. En ligne de commande :
qm snapshot 179 avant-maj-glpi --description "Avant la mise à jour de GLPI" --vmstate 1
qm listsnapshot 179
qm rollback 179 avant-maj-glpi # revient à l'état du snapshot
qm delsnapshot 179 avant-maj-glpi # supprime le snapshot une fois la mise à jour validée
--vmstate 1 inclut la mémoire. Pour un conteneur, ce sont les mêmes sous-commandes de pct (pct snapshot, pct rollback, pct delsnapshot), sans la mémoire.
Les bonnes pratiques :
| Règle | Pourquoi |
|---|---|
| Un snapshot avant chaque opération risquée : mise à jour, changement de configuration, migration d'application | Le retour arrière prend quelques secondes |
| Le supprimer dès que l'opération est validée, en jours, pas en mois | Chaque snapshot garde les anciens blocs : plus il vieillit, plus il occupe d'espace, et une longue chaîne ralentit les écritures |
| Arrêter ou figer l'application si elle écrit beaucoup (une base de données) | Un snapshot sans la mémoire capture le disque comme après une coupure ; la base devra se réparer au retour |
| Prévenir les utilisateurs avant un rollback | Tout ce qui a été écrit depuis le snapshot est perdu : les tickets, les fichiers, les commandes |
| Pas de rollback d'un contrôleur de domaine pendant que l'autre tourne | La réplication de l'annuaire pourrait se corrompre (chapitre 6) |
Un snapshot n'est pas une sauvegarde
C'est la phrase la plus importante du chapitre, et une question classique d'examen.
| Snapshot | Sauvegarde | |
|---|---|---|
| Où | Sur le même stockage que la VM | Sur un autre support, idéalement dans un autre lieu |
| Ce que c'est | Un état figé, qui dépend des données actuelles de la VM | Une copie complète et autonome |
| Si le stockage tombe en panne | Perdu avec la VM | Intact : on restaure la VM ailleurs |
| Si un rançongiciel chiffre la VM | Souvent perdu aussi (un attaquant qui contrôle l'hyperviseur supprime les snapshots) | Protégé s'il est hors de portée de l'attaquant (serveur séparé, copie hors ligne ou immuable) |
| Durée de conservation | Quelques heures ou jours | Des semaines, des mois, des années |
| Retour arrière | Quelques secondes | Quelques minutes à quelques heures |
| Usage | Filet de sécurité avant une manipulation | Protection contre la perte, la panne, le sinistre, l'attaque |
Sauvegarder avec vzdump
vzdump est l'outil de sauvegarde intégré à Proxmox VE. Il produit une archive complète d'une VM ou d'un conteneur : configuration et disques. Il propose trois modes :
| Mode | Fonctionnement | Interruption | Usage |
|---|---|---|---|
| Snapshot | La VM continue de tourner ; l'agent invité fige les systèmes de fichiers un instant, puis la sauvegarde lit les disques | Aucune | Le mode par défaut, pour presque tout |
| Suspend | La VM est mise en pause le temps de la copie (conteneurs : copie en deux passes avec une courte pause) | Courte | Rarement utile avec les VM |
| Stop | La VM est arrêtée proprement, sauvegardée, puis redémarrée | Le temps de la sauvegarde | Une cohérence parfaite, pour un service qui peut s'arrêter la nuit |
Une sauvegarde ponctuelle, dans l'interface : VM, onglet Backup, Backup now. En ligne de commande, vers le stockage local :
vzdump 179 --mode snapshot --storage local --compress zstd --notes-template "{{guestname}} avant migration"
ls /var/lib/vz/dump/
# vzdump-qemu-179-2026_11_03-21_00_04.vma.zst (une VM : format .vma, compressé avec zstd)
# vzdump-qemu-179-2026_11_03-21_00_04.log
Un conteneur donne une archive vzdump-lxc-182-….tar.zst. Pour restaurer, sélectionne la sauvegarde dans le stockage (Backups) et clique sur Restore, ou :
# Restaurer sous un nouveau VMID, pour comparer sans écraser la VM en service
qmrestore /var/lib/vz/dump/vzdump-qemu-179-2026_11_03-21_00_04.vma.zst 279 --storage truenas-nfs
# Restaurer un conteneur
pct restore 282 /var/lib/vz/dump/vzdump-lxc-182-2026_11_03-21_05_12.tar.zst --storage truenas-nfs
Planifier les sauvegardes
Les sauvegardes régulières se planifient au niveau du centre de données : Datacenter > Backup > Add.
| Onglet | Champ | Valeur chez Sorbier |
|---|---|---|
| General | Node | All |
| Storage | pbs-sorbier | |
| Schedule | 21:00 (chaque soir) ; la syntaxe accepte aussi mon..fri 21:00 ou sat 02:00 | |
| Selection mode | All (toutes les VM et tous les conteneurs), ou Include selected VMs, ou Pool based | |
| Mode | Snapshot | |
| Notification | Selon les règles de Datacenter > Notifications : prévenir en cas d'échec | |
| Retention | Keep Daily, Keep Weekly, Keep Monthly | 14, 8, 12 |
| Note Template | {{guestname}} |
Avec un stockage Proxmox Backup Server, la rétention se règle plutôt sur le serveur de sauvegarde lui-même, par une tâche de nettoyage (prune job) : ainsi, un hôte compromis ne peut pas raccourcir la rétention.
Proxmox Backup Server
Proxmox Backup Server (PBS, version 4.x sur Debian 13) est le serveur de sauvegarde de l'éditeur de Proxmox VE. Il s'installe depuis son propre ISO sur une machine séparée du cluster, et s'administre sur https://<adresse>:8007. Chez Sorbier, pbs est un serveur physique installé dans une autre pièce que la salle serveur, avec une patte dans le réseau de stockage (192.168.10.245) et une dans le VLAN d'administration pour son interface web.
Ce que PBS apporte par rapport à des fichiers vzdump sur un NAS :
| Fonction | Ce qu'elle change |
|---|---|
| Déduplication | Les données sont découpées en morceaux identifiés par leur empreinte ; un morceau déjà stocké n'est pas renvoyé. Chaque sauvegarde est complète du point de vue de la restauration, mais ne coûte que ce qui a changé |
| Sauvegarde incrémentale rapide | Proxmox VE garde une carte des blocs modifiés depuis la dernière sauvegarde (dirty bitmap) : seuls ces blocs sont lus |
| Chiffrement côté client | Les données sont chiffrées par Proxmox VE avant d'être envoyées : le serveur de sauvegarde ne les voit jamais en clair |
| Vérification | Une tâche de vérification (verify job) relit les morceaux et contrôle leurs empreintes, pour découvrir une sauvegarde abîmée avant d'en avoir besoin |
| Nettoyage | Les tâches prune appliquent la rétention ; le garbage collection libère les morceaux qui ne servent plus |
| Synchronisation | Une copie vers un second PBS distant (sync job), ou vers des bandes LTO : la copie hors site de la règle 3-2-1 |
| Restauration fine | Restauration d'un seul fichier d'une VM (File Restore), ou démarrage de la VM pendant sa restauration (live-restore) |
Relier Proxmox VE à PBS. Sur le serveur PBS, crée un datastore (ici vms) et un compte dédié aux hôtes, pve-sauvegarde@pbs, avec le rôle DatastoreBackup sur ce datastore : il peut sauvegarder et restaurer, mais pas supprimer de sauvegardes. Puis, dans Proxmox VE, Datacenter > Storage > Add > Proxmox Backup Server :
| Champ | Valeur |
|---|---|
| ID | pbs-sorbier |
| Server | 192.168.10.245 |
| Username | pve-sauvegarde@pbs |
| Password | Son mot de passe (ou un jeton d'API) |
| Datastore | vms |
| Fingerprint | L'empreinte SHA-256 du certificat de PBS, copiée depuis son tableau de bord (Show Fingerprint) |
| Onglet Encryption | Upload an existing client encryption key ou Auto-generate a client encryption key |
L'empreinte sert à authentifier le serveur : le certificat de PBS est auto-signé, et Proxmox VE refuse de se connecter si l'empreinte présentée ne correspond pas à celle qu'il a enregistrée. Un faux serveur placé sur le réseau ne peut donc pas recevoir les sauvegardes.
Les flux à autoriser sont simples : les nœuds se connectent à PBS sur TCP 8007, par le réseau de stockage. Le détail de la politique de sauvegarde de Sorbier (fréquence, rétention, copie hors site, tests de restauration) est construit dans le cours Sauvegarde et PRA. Le sujet 2026 de l'E7 SISR interrogeait précisément ces points : empreinte du certificat, chiffrement, recommandations de l'ANSSI et rétention (annales de l'E7 SISR).
Exercices
Exercice 1 sur 4 Snapshot ou sauvegarde ? Réussi À revoir
Pour chaque situation, dis ce qui permet de s'en sortir : un snapshot, une sauvegarde, ou les deux.
- La mise à jour de GLPI sur
srv-gestionéchoue à 14 h ; il faut revenir à l'état de 13 h 55. - Le NAS TrueNAS perd deux disques de son pool RAIDZ-1 : toutes les VM ont disparu.
- Un rançongiciel a chiffré
srv-fichiersil y a trois jours ; on s'en aperçoit aujourd'hui. - Un technicien a supprimé par erreur un dossier de
srv-fichiersla semaine dernière.
Voir la réponseMasquer la réponse de l'exercice 1
- Un snapshot pris avant la mise à jour : rollback, et l'application revient en quelques secondes.
- Une sauvegarde : les snapshots étaient sur le NAS, ils sont perdus avec lui. On restaure les VM depuis PBS sur un autre stockage.
- Une sauvegarde antérieure à l'infection, conservée assez longtemps (rétention) et hors de portée de l'attaquant (PBS séparé, compte sans droit de suppression, copie hors site). Un snapshot de plus de trois jours n'existerait probablement pas, et l'attaquant aurait pu le supprimer.
- Une sauvegarde : avec PBS, File Restore récupère le seul dossier dans la sauvegarde de la semaine dernière, sans restaurer toute la VM.
Tu avais trouvé ?
Exercice 2 sur 4 Choisir le mode de vzdump Réussi À revoir
Choisis le mode de sauvegarde et justifie : la VM srv-ad (qui doit rester disponible) ; une VM de base de données qui peut être arrêtée de 2 h à 3 h et pour laquelle on veut une cohérence parfaite ; le conteneur ct-horaires.
Voir la réponseMasquer la réponse de l'exercice 2
srv-ad: snapshot, sans interruption, avec l'agent invité qui fige les systèmes de fichiers. La restauration d'un contrôleur de domaine suit ensuite les règles de l'annuaire.- La base de données : stop pendant la fenêtre de 2 h à 3 h : la VM est arrêtée proprement, la sauvegarde est parfaitement cohérente. On peut aussi garder le mode snapshot et compléter par un export de la base faite par le SGBD.
ct-horaires: son disque est un fichier raw sur le partage NFS, sans snapshot possible : vzdump passe automatiquement en mode suspend, avec une pause très courte.
Tu avais trouvé ?
Exercice 3 sur 4 La rétention Réussi À revoir
La tâche de nettoyage de PBS garde 14 sauvegardes quotidiennes, 8 hebdomadaires et 12 mensuelles. Chez Proxmox, une sauvegarde déjà retenue par une règle n'est pas comptée une seconde fois par la suivante.
- Au maximum, combien de sauvegardes d'une VM sont conservées ?
- Jusqu'à quelle ancienneté peut-on remonter, environ ?
- Pourquoi l'espace occupé n'est-il pas 34 fois la taille de la VM ?
Voir la réponseMasquer la réponse de l'exercice 3
- Au plus 14 + 8 + 12 = 34 sauvegardes.
- Les 14 derniers jours au quotidien, puis une sauvegarde par semaine pour les 8 semaines précédentes, puis une par mois pour les 12 mois encore plus anciens : chaque règle ne compte que les sauvegardes plus anciennes que celles déjà retenues. On remonte donc à environ 14 mois (un peu plus d'un an), et non à 12 mois.
- PBS déduplique : chaque sauvegarde ne stocke que les morceaux nouveaux. D'une nuit à l'autre, une VM ne change qu'une petite partie de ses données, si bien que les 34 sauvegardes occupent souvent quelques fois la taille de la VM, pas 34 fois.
Tu avais trouvé ?
Exercice 4 sur 4 Questions de type E7 Réussi À revoir
Sorbier sauvegarde ses VM sur Proxmox Backup Server avec le chiffrement côté client.
- À quoi sert l'empreinte du certificat de PBS enregistrée dans Proxmox VE ? Quelle attaque empêche-t-elle ?
- Le serveur PBS est volé. Le voleur peut-il lire les données des sauvegardes ? Justifie.
- L'hôte qui garde la clé de chiffrement brûle avec la salle serveur. Que se passe-t-il pour les sauvegardes, et quelle mesure aurait évité le problème ?
- Pourquoi le compte utilisé par les hôtes a-t-il le rôle DatastoreBackup et non DatastoreAdmin ?
Voir la réponseMasquer la réponse de l'exercice 4
- Elle authentifie le serveur : Proxmox VE vérifie que le certificat présenté est bien celui de son PBS, même s'il est auto-signé. Elle empêche une attaque de l'homme du milieu : un faux serveur qui intercepterait les connexions présenterait un autre certificat, et la connexion serait refusée.
- Non : les données ont été chiffrées par Proxmox VE avant l'envoi, avec une clé que PBS n'a jamais eue. Le voleur n'a que des morceaux chiffrés (il voit seulement les identifiants des VM et les dates des sauvegardes).
- Sans la clé, les sauvegardes sont illisibles : elles sont perdues. Il fallait exporter la clé dès sa création et en garder une copie hors du système d'information (coffre de mots de passe, copie papier au coffre, dans un autre bâtiment).
- Par moindre privilège : un hôte compromis, par exemple par un rançongiciel, pourrait avec DatastoreAdmin supprimer toutes les sauvegardes avant de chiffrer les VM. Avec DatastoreBackup, il peut seulement en ajouter et relire les siennes ; la suppression et la rétention restent gérées sur PBS.
Tu avais trouvé ?