Exercice 4 — Sauvegarder l'infrastructure de Cyclo-Nord¶

Durée : ~60 min · En équipe · Théorie associée : Sauvegarder une VM et la remettre en place

Objectif¶

Produire une sauvegarde des trois VM de Cyclo-Nord et du template, réunir le tout dans un dossier partagé par l'équipe, puis prouver que ces archives sont bonnes en détruisant la caisse et en la reconstruisant à partir de la sienne.

C'est le premier jalon du TP1

Les fichiers que vous produisez aujourd'hui sont le point de départ du TP1, et ils comptent dans sa note. Au prochain cours, les serveurs auront été remis à zéro pour le groupe suivant : vous restaurerez ces archives et vous repartirez de là pour importer le site web et le serveur de fichiers venus de VMware ESXi. Sans ces fichiers, vous recommencez l'exercice 3 au complet.

Prérequis¶

L'exercice 3 terminé : les trois VM tournent et la caisse encaisse une vente.
Une vente déjà enregistrée dans la base, comme à l'étape 22 de l'exercice 3.
Le numéro de chaque serveur de l'équipe, noté #, pour les adresses 10.70.44.#.
Un dossier OneDrive partagé entre les membres de l'équipe, créé avant de commencer.

Ce que vous produisez¶

Machine	ID	Fichier attendu
`fw-cyclonord`	401	`vzdump-qemu-401-<date>.vma.zst`
`caisse`	402	`vzdump-qemu-402-<date>.vma.zst`
`srv-donnees`	403	`vzdump-qemu-403-<date>.vma.zst`
`tmpl-debian13`	9000	`vzdump-qemu-9000-<date>.vma.zst`

Chaque machine se sauvegarde sur le nœud qui l'héberge. Une sauvegarde ne se déplace pas d'elle-même vers un autre serveur, et le panneau Backup d'une VM n'écrit que sur les stockages de son propre nœud. Si vos trois VM sont réparties sur trois serveurs, vous ferez donc la manipulation sur trois serveurs.

Les captures de ce document viennent d'une démonstration faite sur un seul nœud, avec d'autres identifiants de VM que les vôtres. Une image peut donc afficher 100 ou 101 là où votre écran affiche 402 ou 403. Fiez-vous au tableau ci-dessus, pas aux numéros des captures : les écrans, eux, sont les mêmes.

Le template 9000 existe sur chaque serveur de l'équipe, et les copies sont interchangeables. Une seule suffit dans le dossier partagé : désignez la personne qui la produit.

Étape 0 — Sauvegarder la configuration de la Switch¶

Dans MobaXTerm, lancez les commandes suivantes:

Bash

terminal length 0

Bash

show running-config

La première commande empêche le switch de découper sa sortie en pages, qu'il faudrait autrement faire défiler une à une. Le fichier doit être du texte, pas une capture d'écran. Une configuration en texte se relit, se cherche, se compare d'une version à l'autre, et surtout se recolle dans un switch : c'est exactement ce que vous ferez à la semaine 5 si le switch a été remis à zéro.

Relisez-le avant de le déposer. Il doit contenir :

les cinq VLAN, avec leur nom : 10 bureaux, 20 serveurs, 30 dmz, 460, 700 ;
les ports des serveurs en switchport mode trunk, avec native vlan 700 et allowed vlan 10,20,30,460,700 ;
l'uplink vers la salle des serveurs, en trunk, limité aux VLAN du collège (460,700) ;
le port du poste en switchport mode access sur le VLAN 20 ;
le nom du switch, sw-cyclonord.

Chaque port y apparaît sous la forme d'un bloc interface. Celui d'un port de serveur ressemble à ceci :

Texte

interface GigabitEthernet1/0/1
 description serveurs proxmox
 switchport trunk native vlan 700
 switchport trunk allowed vlan 10,20,30,460,700
 switchport mode trunk
 spanning-tree portfast trunk

Étape 1 — Vérifier le stockage des sauvegardes¶

Sur le nœud qui héberge le pare-feu, sélectionnez local (pve#) dans l'arborescence, puis Summary.

La ligne Content contient déjà Backup. Vous n'avez rien à configurer : un stockage de type Directory accepte les sauvegardes dès son installation, et local est celui que Proxmox crée à l'installation.

Regardez aussi la ligne Usage. Comptez environ 1 Go libre par machine à sauvegarder sur ce nœud.

Étape 2 — Sauvegarder le pare-feu¶

Sélectionnez la VM 401 dans l'arborescence, puis Backup, et cliquez sur Backup now.

Remplissez la fenêtre avec ces valeurs.

Champ	Valeur
Storage	`local`
Mode	`Snapshot`
Compression	`ZSTD (fast and good)`
Protected	décoché pour l'instant
Notes	`{{guestname}}`

Le mode Snapshot laisse le pare-feu allumé pendant toute l'opération. Vos deux autres VM continuent donc de sortir sur Internet, et la caisse reste joignable : personne ne remarque la sauvegarde.

Cliquez sur Backup.

Étape 3 — Lire le journal de la tâche¶

La fenêtre Task viewer s'ouvre et affiche le journal au fur et à mesure. Laissez-la ouverte jusqu'à la dernière ligne.

Trois lignes méritent votre attention, à la fin :

backup is sparse: 30.40 GiB (94%) total zero data — le disque déclaré fait 32 Go, mais 94 % n'ont jamais servi. Proxmox ne copie pas ces blocs vides.
archive file size: 676MB — c'est ce qui reste une fois les blocs vides écartés et le reste compressé.
Finished Backup of VM 401 (00:00:14) — quatorze secondes pour une machine de 32 Go.

Vos chiffres seront proches sans être identiques : ils dépendent de ce que le pare-feu a écrit depuis sa création.

Fermez la fenêtre. L'archive apparaît maintenant dans la liste, avec son nom, sa date et sa taille.

Étape 4 — Sauvegarder le serveur de données¶

Placez-vous sur le nœud qui héberge srv-donnees, sélectionnez la VM 403 puis Backup > Backup now, avec les mêmes valeurs qu'à l'étape 2.

Cette machine porte la base de données des ventes, et elle écrit dedans en continu. Le qemu-guest-agent installé par cloud-init à l'exercice 3 sert précisément ici : il vide les tampons d'écriture du système avant la photo du disque.

Étape 5 — Sauvegarder la caisse¶

Placez-vous sur le nœud qui héberge caisse, sélectionnez la VM 402 puis Backup > Backup now, avec les mêmes valeurs.

La caisse est un clone lié du template 9000 : son disque ne contient que ce qui la distingue du modèle. L'archive, elle, est complète. vzdump lit le disque tel que la VM le voit, base comprise, et produit un fichier qui n'a plus besoin du template pour être restauré.

Étape 6 — Sauvegarder le template¶

Un template se sauvegarde comme une VM. Sélectionnez 9000 dans l'arborescence, puis Backup > Backup now, avec les mêmes valeurs qu'à l'étape 2.

Deux lignes changent par rapport aux précédentes. Le journal annonce status = stopped puis backup mode: stop, alors que vous aviez choisi Snapshot : un template est toujours éteint, donc Proxmox prend l'archive directement sur le disque au lieu de passer par une vue instantanée. Proxmox corrige donc le mode de lui-même, et sa correction est la bonne.

L'archive contient la ligne template: 1. Une fois restaurée, la machine revient comme template, prête à être clonée, sans que vous ayez à la reconvertir.

Étape 7 — Lire la machine contenue dans l'archive¶

Revenez sur le nœud du pare-feu. Sélectionnez local (pve#) puis l'onglet Backups, cliquez sur la ligne de la VM 401, puis sur Show Configuration.

Vous lisez le fichier de configuration de la VM, tel qu'il était au moment de la sauvegarde et tel qu'il est stocké à l'intérieur de l'archive :

les trois cartes réseau, avec leur bridge, leur étiquette VLAN et leur adresse MAC ;
la mémoire, les cœurs, le nom, l'ordre de démarrage ;
le disque et sa taille.

C'est ce qui sépare une sauvegarde Proxmox d'une copie de disque. Restaurez cette archive et le pare-feu revient branché sur les VLAN 460, 20 et 30, sans que vous ayez une seule case à recocher.

Étape 8 — Protéger les archives¶

Toujours dans l'onglet Backups du stockage, la ligne de la VM 401 étant sélectionnée, cliquez sur Change Protection.

Un bouclier apparaît sur la ligne, et le bouton Remove devient grisé. Une archive protégée ne peut plus être supprimée, ni par une manœuvre accidentelle, ni par une tâche de nettoyage automatique.

Faites la même chose pour chacune des autres archives, sur chacun des nœuds concernés.

Étape 9 — Ouvrir une invite de commandes sur votre poste¶

Les archives sont sur les disques des serveurs. C'est le dernier endroit où les laisser : ce sont ces disques qui seront remis à zéro pour le groupe suivant.

Ouvrez PowerShell sur votre poste et créez le dossier qui recevra les fichiers.

PowerShell

cd $HOME\Documents

PowerShell

mkdir tp1-cyclonord

PowerShell

cd tp1-cyclonord

Étape 10 — Descendre les archives sur votre poste¶

Proxmox n'offre aucun bouton de téléchargement pour les sauvegardes. Elles se récupèrent en scp, le copieur de fichiers d'OpenSSH, présent dans Windows.

PowerShell

scp root@10.70.44.#:/var/lib/vz/dump/vzdump-qemu-*.vma.zst .

Remplacez # par le numéro d'un serveur de l'équipe. Le * laisse le serveur compléter lui-même : toutes les archives présentes sur ce nœud descendent en une seule commande.

La première connexion affiche un avertissement sur l'empreinte de la machine : répondez yes. Entrez ensuite le mot de passe root du nœud, celui défini à l'installation de Proxmox.

Répétez la commande pour chaque serveur de l'équipe qui héberge une des machines, en changeant le numéro.

PowerShell

dir

Étape 11 — Réunir les archives de l'équipe¶

Déposez vos fichiers dans le dossier OneDrive partagé de l'équipe. À la fin, ce dossier doit contenir quatre archives : une par VM de Cyclo-Nord, plus celle du template.

C'est ce dossier, et lui seul, qui vous servira au prochain cours. Chacun doit pouvoir y accéder : si la personne qui détient l'archive du pare-feu est absente la semaine prochaine, l'équipe ne démarre pas.

Le dossier Documents de votre poste ne suffit pas

Les postes de la salle sont réinitialisés, et rien ne garantit que vous reprendrez le même la semaine prochaine. Un fichier qui n'existe qu'à un seul endroit n'est pas sauvegardé, et c'est vrai aussi pour le vôtre.

Étape 12 — Éteindre la caisse¶

Une sauvegarde qu'on n'a jamais restaurée n'est pas une sauvegarde. Vous allez donc détruire la caisse et la reconstruire.

Sur le nœud qui l'héberge, sélectionnez la VM 402 et cliquez sur Shutdown. Attendez que l'icône de la VM devienne grise dans l'arborescence.

Proxmox refuse de supprimer une machine allumée : le bouton reste grisé tant qu'elle tourne.

Étape 13 — Détruire la caisse¶

VM 402 toujours sélectionnée, ouvrez le menu More en haut à droite, puis Remove.

Proxmox demande de retaper l'identifiant 402 pour confirmer. Faites-le, puis validez.

Vous détruisez une VM et son disque

Cette suppression est définitive et ne se défait pas. Vérifiez avant de cliquer que l'archive de l'étape 5 est bien dans la liste des sauvegardes, et que le fichier est bien dans le dossier partagé.

La VM disparaît de l'arborescence. Son archive, elle, reste dans le panneau Backups du stockage : supprimer une machine ne supprime pas ses sauvegardes.

Étape 14 — Constater la panne¶

Depuis votre poste, rechargez http://192.168.30.10.

La boutique est à l'arrêt. Le pare-feu tourne toujours, la base de données aussi, et les ventes déjà encaissées sont intactes sur srv-donnees : c'est la machine de la caisse qui manque.

Étape 15 — Restaurer la caisse¶

Sur le même nœud, sélectionnez local (pve#) puis l'onglet Backups. Cliquez sur la ligne vzdump-qemu-402-..., puis sur Restore.

Champ	Valeur
Storage	`From backup configuration`
VM	`402`
Unique	décoché
Start after restore	coché

Proxmox propose d'office le premier identifiant libre. Remplacez-le par 402 : vous voulez la machine d'avant, à sa place, pas une copie à côté.

Laissez Unique décoché. Cochée, cette case tirerait de nouvelles adresses MAC ; ici vous voulez exactement l'inverse, puisque la machine d'origine n'existe plus et que vous reconstruisez la même.

Cliquez sur Restore.

Étape 16 — Vérifier que la boutique est revenue¶

Attendez une minute que la VM démarre, puis rechargez http://192.168.30.10 depuis votre poste.

Vous n'avez rien reconfiguré. Ni l'étiquette VLAN 30, ni l'adresse 192.168.30.10, ni la règle du pare-feu qui ouvre le port 3306 : la première était dans l'archive, la deuxième aussi, et la troisième n'a jamais bougé puisqu'elle vit dans le pare-feu.

Le conteneur Docker de la caisse redémarre de lui-même, parce qu'il a été lancé avec --restart unless-stopped à l'exercice 3.

Étape 17 — Encaisser une vente sur la machine restaurée¶

Ajoutez un article au panier et cliquez sur Encaisser, puis allez vérifier dans la base, depuis la console de srv-donnees :

Bash

sudo docker exec db mariadb -upos -p'Motdepasse123!' pos -e "SELECT id, boutique, total FROM ventes;"

Deux lignes. La première a été encaissée par une machine qui n'existe plus, la seconde par celle que vous venez de reconstruire. Les données n'ont jamais été en danger : elles vivent sur une autre VM, dans un autre réseau. C'est exactement ce que la propriétaire de Cyclo-Nord avait demandé.

Vérification finale¶

Chaque archive apparaît dans le panneau Backups du stockage local de son nœud
Les quatre archives portent la marque de protection
Show Configuration sur l'archive de la VM 401 affiche net0, net1 et net2 avec leurs tags
Le dossier OneDrive partagé contient les quatre fichiers .vma.zst
Chaque membre de l'équipe peut ouvrir ce dossier
La VM 402 a été détruite puis restaurée sous le même identifiant
http://192.168.30.10 affiche à nouveau la caisse
La table ventes contient une vente d'avant la destruction et une d'après

Question 1¶

La caisse restaurée revient dans le VLAN 30 avec l'adresse 192.168.30.10, sans que vous ayez rien saisi. D'où vient cette information ?

a) Du template 9000, dont la caisse est un clone lié.
b) Du fichier de configuration de la VM, stocké à l'intérieur de l'archive avec les disques.
c) Du serveur DHCP du VLAN 30, qui a réattribué la même adresse.

Voir la réponse

**b) Du fichier de configuration de la VM, stocké à l'intérieur de l'archive avec les disques.** C'est ce que **Show Configuration** vous a montré à l'étape 7 : l'archive contient la description complète de la machine, cartes réseau et étiquettes VLAN comprises, en plus du contenu du disque. Le choix c) ne tient pas : aucun serveur DHCP ne tourne dans le VLAN 30. L'adresse de la caisse est fixe, posée par cloud-init, et cette configuration fait partie de ce que vzdump a sauvegardé.

Question 2¶

Vous voulez vérifier une archive sans toucher à la VM qui tourne encore. Que changez-vous par rapport à l'étape 15 ?

a) Rien, il suffit de restaurer : Proxmox refuse d'écraser une VM allumée.
b) Vous gardez l'identifiant libre proposé par Proxmox et vous cochez Unique.
c) Vous restaurez sur un autre stockage, ce qui suffit à séparer les deux machines.

Voir la réponse

**b) Vous gardez l'identifiant libre proposé par Proxmox et vous cochez Unique.** L'identifiant libre vous donne une seconde machine au lieu d'en remplacer une. La case **Unique** tire de nouvelles adresses MAC : sans elle, la copie arriverait avec celles de l'archive, donc les mêmes que l'originale, et les deux machines se disputeraient le trafic sur le bridge. Le choix c) ne règle que la question du disque. Deux VM peuvent très bien vivre sur deux stockages différents et porter la même adresse MAC sur le même réseau : c'est la couche 2 qui casse, pas le stockage.

En cas de problème¶

Symptôme	Cause probable	Correction
Backup now est grisé	Aucun stockage du nœud n'accepte le contenu `Backup`	Étape 1, vérifier la ligne Content de `local`
La VM à sauvegarder n'est pas dans l'arborescence	Vous êtes sur le mauvais nœud de l'équipe	Chaque VM se sauvegarde depuis le nœud qui l'héberge
La sauvegarde s'arrête sur `no space left on device`	Le disque du nœud est plein	Supprimer d'anciennes ISO dans `local`, puis relancer
Le journal affiche `skipping guest filesystem freeze`	La VM n'a pas de `qemu-guest-agent`, ou l'option est désactivée	Normal pour le pare-feu ; à corriger sur `403` et `402`
`scp` répond `Connection refused`	Mauvais numéro de serveur, ou nœud éteint	Vérifier que `https://10.70.44.#:8006` répond
`scp` répond `No such file or directory`	Le chemin est mal recopié	`ls /var/lib/vz/dump/` dans le Shell du nœud
`scp: command not found`	La commande a été tapée dans l'invite `cmd`	Utiliser PowerShell
Remove reste grisé	La VM tourne encore	Étape 12, l'éteindre d'abord
La restauration échoue sur `volume already exists`	Un disque de l'ancienne VM 402 subsiste	Datacenter > Storage > local-lvm, supprimer `vm-402-disk-0`
La caisse restaurée ne répond pas	La VM n'a pas redémarré	La démarrer à la main, puis `sudo docker ps` dans sa console
La caisse affiche « base de données injoignable »	`srv-donnees` a redémarré et le conteneur `db` ne tourne pas	`sudo docker start db` sur `srv-donnees`

Pour aller plus loin¶

Datacenter > Backup permet de créer une tâche planifiée qui sauvegarde plusieurs VM à heure fixe, avec une politique de rétention. C'est ce qu'on met en place en production, et c'est le sujet de la semaine 7.
Comparez la taille de l'archive du pare-feu avec celle du template. Les deux disques sont déclarés bien plus gros que les fichiers obtenus : cherchez la ligne backup is sparse de chaque journal pour comprendre l'écart.