Mode opératoire — Sauvegarder les machines virtuelles d’un lab sur Proxmox, et prouver qu’on sait les restaurer

Document autonome. Partie théorique, puis mise en œuvre telle qu’elle a été réalisée et vérifiée sur l’hyperviseur Proxmox de l’école (phase 13 du suivi). La méthode vaut pour toute infrastructure virtualisée sous Proxmox VE dont on dispose d’un stockage réseau. Le contexte de l’infrastructure est dans Documentation-pfSense.md (étape 43) ; l’accès externe au lab, traité à part, est dans MO-10-Pangolin.md.

Valeurs masquées. Aucun mot de passe ni identifiant n’apparaît ici.

Dernière mise à jour : 15/10/2026 — la première exécution automatique est contrôlée (§8)

Suite, depuis le 15/10 : la tâche planifiée envoie désormais ses sauvegardes à un Proxmox Backup Server (sauvegardes incrémentales, rétention faite par PBS) : voir MO-12-Proxmox-Backup-Server.md. Ce MO reste la référence pour les principes (mode snapshot, sauvegarde par pool, test de restauration).

Sommaire

1 · Le besoin et la situation de départ

1.1 Pourquoi

1.2 La situation technique

2 · Théorie : ce qu’est une sauvegarde de VM, et ce qu’elle n’est pas

2.1 Le mécanisme : vzdump

Proxmox sauvegarde une VM avec l’outil vzdump : il lit les disques de la VM et écrit une archive (un fichier) sur un stockage. Pour une VM, l’archive est au format vma, ici compressée en zstd (.vma.zst).

2.2 Les trois modes

C’est le mode retenu : le lab reste en service.

2.3 La cohérence : ce que « snapshot » garantit et ne garantit pas

Si la VM a l’agent invité (qemu-guest-agent) actif, Proxmox lui demande de geler brièvement le système de fichiers (fs-freeze) avant l’instant, puis de le dégeler (fs-thaw). La sauvegarde est alors cohérente côté fichiers. Sans agent, elle est dite « cohérente après plantage » : comme si la machine avait été coupée net.

Les bases de données redémarrent presque toujours seules après un arrêt brutal, mais ce n’est pas une garantie. Pour des bases importantes, un export logique (un fichier SQL produit par le serveur lui-même) est une protection complémentaire. Il n’est pas fait ici.

2.4 La rétention : combien de temps garder

On ne garde pas tout : l’espace est limité. La rétention règle ce qui est supprimé automatiquement.

Une semaine permet de revenir sur une erreur récente, un mois sur une erreur découverte tard.

2.5 La règle 3-2-1, et pourquoi elle compte ici

Trois copies des données, sur deux supports différents, dont une hors site. Une sauvegarde qui partage son support avec la donnée ne protège pas contre la panne de ce support.

2.6 Une sauvegarde jamais restaurée n’est pas une sauvegarde

Seule une restauration réussie prouve que l’archive est exploitable. C’est pourquoi le §5 vient avant la tâche planifiée (§7).

3 · État des lieux avant de construire

Rien n’est créé dans cette partie : on lit.

Hyperviseur partagé : ne sauvegarder que son pool. La liste des VM visibles contient celles des autres élèves. Une tâche réglée sur « All » les sauvegarderait toutes sur le NAS commun.

4 · Première sauvegarde, à la main, d’une seule VM

Avant d’automatiser, on mesure sur une machine : taille, durée, comportement.

4.1 Lancer

Choisir une VM simple et peu critique (ici srv-web-01, VM 110). Dans Proxmox : clic sur la VM → onglet Backup → Backup now.

La commande réellement exécutée figure en première ligne du journal :

vzdump 110 --remove 0 --mode snapshot --notes-template '{{guestname}}' --node pve-01 --compress zstd --notification-mode notification-system --storage Syno

4.2 Lire le journal

Validation : l’archive apparaît dans Stockage Syno → Backups.

non déposée : le journal de la tâche (fichier texte conservé par Axel).

4.3 Deux lignes d’avertissement à comprendre

WARN: 'root@pam' does not have a configured email address ...
ERROR: could not notify via target `mail-to-root` ...

La sauvegarde est réussie (TASK OK) : seul l’envoi du courriel de rapport échoue, faute d’adresse. Mais cela veut dire qu’une sauvegarde qui échouerait ne préviendrait personne.

5 · Le test de restauration

On restaure l’archive en une nouvelle VM, sans toucher à la VM d’origine.

5.1 Lancer

Stockage Syno → Backups → clic sur l’archive → Restore.

5.2 Ce que montre le journal de restauration

La restauration est donc plus rapide que la sauvegarde (11 min).

5.3 Le piège : deux machines identiques

Avec les valeurs par défaut, la case Unique n’est pas cochée. La copie a alors la même adresse MAC et la même configuration réseau que la VM d’origine : démarrée sur le même réseau, elle provoquerait un conflit d’adresses (et, pour un contrôleur de domaine, des désordres plus graves). Parades, cumulables :

1. cocher Unique à la restauration ;
2. débrancher la carte réseau de la copie avant de la démarrer : Hardware → Network Device → Edit → Disconnect ;
3. ou éteindre la VM d’origine pendant le test.

5.4 Vérifier que la copie est exploitable

Démarrer la copie, ouvrir sa Console, se connecter, puis vérifier ce qui prouve que la machine est exploitable : son nom (hostname), que son service principal est actif, et que les données de l’application sont présentes. Le contrôle exact dépend de la machine restaurée.

Résultat obtenu sur la VM d’essai : la copie démarre, avec son nom et ses données d’origine.

6 · Remettre le lab en état

À faire dans cet ordre :

1. Arrêter la VM de test (136).
2. Redémarrer la VM d’origine si elle a été éteinte pendant le test.
3. Vérifier que le service répond : ici, la page de statistiques du répartiteur doit montrer le serveur web en vert.
4. Supprimer la VM de test (clic droit → More → Remove, en laissant cochée la destruction de ses disques) : sinon ses 32 Go restent occupés.

Redémarrer la VM d’origine avant de supprimer la copie, au cas où l’on aurait encore besoin de cette dernière.

7 · La tâche planifiée

Datacenter → Backup → Add.

La liste affichée par l’assistant doit montrer exactement les 11 VM du pool.

Pourquoi « Pool based » : la tâche ne sauvegarde que les VM du pool, et toute VM ajoutée ensuite est incluse sans modifier la tâche. Avec « All », les VM de tous les élèves partiraient sur le NAS commun.

« Repeat missed » relance la tâche dès que possible si l’hyperviseur était éteint à l’heure prévue. Décochée, la sauvegarde de cette nuit-là est perdue sans rattrapage. Cochée (choix retenu), elle peut démarrer en journée après un redémarrage.

Validation : une ligne apparaît dans Datacenter → Backup avec la colonne Next Run (le prochain 02:00), le stockage Syno et la rétention.

Notifications : l’envoi de courriel échoue (§4.3). Ne pas renseigner d’adresse sur root@pam : c’est le compte administrateur partagé de l’hyperviseur.

8 · Vérifier la première exécution automatique (15/10/2026)

La tâche s’est exécutée seule la nuit suivant sa création. Le journal de la tâche (Datacenter → Backup, ou le panneau Tasks, bouton de téléchargement du journal) donne tout ce qu’il faut contrôler.

8.1 Ce qui a été contrôlé

8.2 Taille et durée de chaque VM

• L’estimation faite avant (≈ 40 Go par nuit) était trop basse : elle extrapolait une seule mesure, un petit serveur web. Le poste Windows et le contrôleur de domaine pèsent à eux deux plus de 55 Go.
• Avec la rétention (jusqu’à 11 versions conservées), l’ordre de grandeur monte à ≈ 0,8 To, pour environ 2,1 To libres au départ. Ce chiffre est une projection, à recontrôler après une semaine d’exécutions.

La durée dépend de l’endroit où se trouve le disque de la VM, pas de sa taille. Les VM dont le disque est sur le stockage local de l’hyperviseur sont sauvegardées en 1 à 2 minutes (plus d'1 Go/s). Celles dont le disque est sur le NAS prennent de 8 à 40 minutes (25 à 90 Mo/s) : la machine lit et écrit sur le même NAS.

8.3 Ce que le journal signale

Aucune de ces lignes n’a empêché la tâche de se terminer (TASK OK) : une tâche peut se terminer avec succès alors que le gel d’une VM a échoué ; c’est donc le journal, pas seulement le statut final, qu’il faut lire.

8.4 Reste à contrôler

9 · Pièges et checklist

 Un stockage de sauvegarde existe et a de la place
 Une sauvegarde manuelle d'UNE VM réussie, taille et durée relevées
 Une restauration réussie vers un NOUVEL identifiant, réseau débranché ou MAC unique
 La copie restaurée démarre et ses données applicatives sont présentes
 La copie de test supprimée, la VM d'origine redémarrée et vérifiée
 Tâche planifiée en mode « Pool based », sur le bon pool uniquement
 Rétention réglée, « Keep all backups » décoché
 La première exécution automatique contrôlée (§8)

La règle à retenir en une phrase

Une sauvegarde ne vaut que par la restauration qu’on a réussie : on mesure sur une machine, on restaure sous un autre identifiant en isolant le réseau, et seulement ensuite on automatise, sur son pool uniquement.