Mise en place de la sauvegarde de l’infrastructure avec Proxmox Backup Server
Règle 3-2-1 : 14 machines sauvegardées chaque nuit, copie hors site, quatre restaurations testées.
Seul, dans le laboratoire de l’école qui reproduit l’informatique du siège de GSB (Galaxy Swiss Bourdin, laboratoire pharmaceutique fictif du cas d’étude de la formation).
Compétences mises en œuvre
| Compétence | Ce que j’ai fait | Preuve |
|---|---|---|
| Gérer le patrimoine informatique | ||
| Gérer des sauvegardes | Sauvegarde automatique et incrémentale des 14 machines chaque nuit, 7 jours conservés, export SQL des bases, copie hors site, notifications, alertes | figures 1 à 3 |
| Vérifier les conditions de la continuité d’un service informatique | Quatre restaurations testées (machine depuis le lab, machine depuis la copie hors site, base depuis l’export) et relecture complète de la copie hors site | tests, figures 4 et 5 |
| Mettre en place et vérifier les niveaux d’habilitation associés à un service | Compte et jeton dédiés pour l’hyperviseur, limités à l’envoi : il ne peut pas supprimer ses sauvegardes, la rétention est faite par PBS seul ; copie hors site dans un compartiment dédié, sous quota, accès refusé sans clé (vérifié) | choix techniques, figure 2 |
Contexte et besoin
Au 14 octobre, mon laboratoire comptait onze machines virtuelles sur un hyperviseur partagé avec d’autres élèves, et aucune tâche de sauvegarde : seulement des exports faits à la main. L’annexe II.E de l’épreuve exige une solution de sauvegarde ; surtout, un cluster de bases, un annuaire et un site reconstruits depuis zéro représentent des semaines de travail.
Il fallait donc une sauvegarde automatique de toutes les machines, testée par une restauration, qui ne recopie pas chaque nuit ce qui n’a pas changé, qui prévienne quand quelque chose échoue, et qui ne dépende pas d’un seul lieu : c’est la règle 3-2-1 (trois copies, deux supports, une hors site), complétée par le « 0 » : zéro erreur à la vérification, parce qu’une copie jamais relue ne prouve rien.
Objectifs et contraintes
Objectifs
- Sauvegarder chaque nuit toutes les machines du laboratoire, et elles seules.
- Prouver chaque sauvegarde par une restauration.
- Ne recopier que ce qui a changé, et séparer les disques des machines de leurs sauvegardes.
- Être prévenu d’un échec ; voir l’état des sauvegardes dans la supervision.
- Appliquer la règle 3-2-1 et la vérifier : trois copies sur deux supports dont une hors site, chaque copie relue et restaurée au moins une fois.
Contraintes
- Un hyperviseur partagé : la tâche ne doit toucher que mes machines, et je n’y mets ni adresse de courriel ni mot de passe.
- Aucune règle entrante dans le pare-feu depuis le réseau de l’établissement, sauf exception justifiée et limitée à une source, un port, une destination.
- Aucune clé à perdre : un chiffrement côté client rendrait tout illisible si la clé disparaissait.
- Un budget nul : logiciels libres, le stockage de l’établissement, et 200 Gio au plus sur un stockage personnel pour la copie hors site.
Analyse et choix techniques
| Question | Mon choix | Pourquoi |
|---|---|---|
| Quel outil ? | D’abord la sauvegarde intégrée de l’hyperviseur (vzdump), puis Proxmox Backup Server (PBS) dès le lendemain | vzdump recopiait tout chaque nuit (environ 75 Go, 2 h 25). PBS découpe en blocs et ne garde que les blocs nouveaux : la même machine passe de 10 min 58 s à 1 min 33 s, puis 2 s quand rien n’a changé |
| Comment appliquer 3-2-1 ? | 3 copies (disques des machines, PBS, hors site) ; 2 supports (miroir de l’hyperviseur, stockage objet) ; 1 hors site (chez moi, par Internet) ; 0 : vérification et relecture | Une copie jamais relue compte pour zéro ; le « 1 » hors ligne de 3-2-1-1-0 manque (voir les limites) |
| Quelles machines ? | Sélection « par pool » (le pool de mes machines) | Réglée sur « toutes », la tâche sauvegarderait les machines de tous les élèves |
| Où stocker ? | Un miroir de deux disques de 6 To de l’hyperviseur, séparé du stockage qui porte les disques des machines | Donnée et sauvegarde sur le même support ne protègent de rien ; le miroir est sain et spacieux |
| Qui a quels droits ? | L’hyperviseur : un jeton qui envoie, sans pouvoir supprimer ; la rétention est faite par PBS. La copie hors site : compartiment dédié, quota, clés S3, HTTPS | Un hyperviseur compromis ne peut pas effacer l’historique ; sans clé, l’accès à la copie est refusé (vérifié) |
| Chiffrer côté client ? | Non | Une clé perdue rendrait tout illisible ; le datastore est déjà dans un lieu contrôlé |
| D’où partent les notifications ? | De PBS, par SMTP chiffré, vers un point de contact dédié | Rien de personnel sur l’hyperviseur partagé |
| Comment copier hors site ? | Le datastore S3 de PBS vers un stockage objet (SeaweedFS) sur mon stockage personnel, en HTTPS | Un montage réseau à travers Internet serait lent et fragile ; un second PBS serait une machine de plus |
| Et les bases de données ? | Un export SQL chaque nuit sur le nœud de secours du cluster, en plus de la sauvegarde des machines | Une sauvegarde de machine restaure une machine entière ; un export restaure une base, sur n’importe quel serveur, en une commande |
Ce que j’en retiens : une sauvegarde jamais restaurée n’est pas une sauvegarde. Chaque étape de cette réalisation s’est terminée par une restauration, avant même de planifier la suivante.
Mise en œuvre
Figure 1 · La règle 3-2-1 appliquée : hyperviseur, serveur PBS, copie hors site, export SQL, nuit par nuit.
- Première sauvegarde à la main (14 octobre) d’une seule machine, vers le stockage de l’établissement, puis restauration dans une machine neuve, sous un nouvel identifiant et avec une nouvelle adresse matérielle : la copie démarre, le site est présent. La copie de test est supprimée ensuite.
- Tâche planifiée : chaque nuit à 2 h, sélection par pool, mode instantané ; première exécution automatique contrôlée le 15 octobre (11 machines, 2 h 25).
- Le serveur PBS (15 octobre) : machine dédiée dans la zone d’administration, compte dédié et jeton pour l’hyperviseur, datastore de 500 Go ; une seule règle entrante dans le pare-feu, de l’hyperviseur vers PBS sur un seul port. Rétention 7 jours à 5 h, ramasse-miettes à 6 h, vérification le samedi.
- Les disques : disques des machines et datastore séparés ; après mesure, les disques des machines sont revenus sur le stockage le plus rapide et le datastore est parti sur le miroir de 6 To (22 et 23 octobre).
- Les notifications (23 octobre) : cible SMTP sur PBS, mails de rétention, de ramasse-miettes et de vérification reçus chaque jour.
- La supervision : une alerte « Sauvegarde trop ancienne » (plus de 26 h) par machine, une ligne par machine et la place occupée dans le tableau de bord.
- L’export SQL (5 novembre) : chaque nuit à 1 h 30 sur le nœud de secours, un fichier compressé par base (site, Grafana, GLPI, puis Matomo le 11 novembre), 7 jours conservés, aucun mot de passe stocké.
- La copie hors site (5 novembre) : stockage objet sur mon stockage personnel, quota de 200 Gio, accès refusé sans clé ; copie à 4 h de la dernière sauvegarde de chaque machine, trois copies conservées ; trois règles d’alerte pour la copie (trop ancienne, machine absente, stockage injoignable), toutes trois éprouvées les 11 et 12 novembre.
- La restauration depuis la copie hors site (6 novembre) : une machine restaurée dans une machine neuve, carte réseau débranchée pour éviter un doublon d’adresse.
Figure 2 · La tâche de l’hyperviseur : 2 h, pool de mes machines, stockage PBS, rétention confiée à PBS.
Figure 3 · Le tableau de bord : une ligne par machine, la sauvegarde de la nuit, la place occupée.
Tests et recette
| Test | Résultat |
|---|---|
| Restauration d’une sauvegarde vzdump (14 octobre) | 3 min 20 s ; la copie démarre, site présent |
| Première nuit automatique vers le stockage de l’établissement (15 octobre) | 11 machines, aucune erreur, 2 h 25 |
| Première sauvegarde vers PBS, puis la seconde aussitôt après | 1 min 33 s, puis 2 s (99 % des blocs réutilisés) |
| Restauration d’une sauvegarde PBS (15 octobre) | Image de 32 Gio en 100 s ; copie supprimée ensuite |
| Première nuit automatique vers PBS (16 octobre) | 11 machines en 36 min, contre 2 h 25 en vzdump |
| Vérification hebdomadaire de PBS (24 octobre) | Réussie ; place occupée stabilisée autour de 35 % du datastore |
| Alerte « Sauvegarde trop ancienne » (29 octobre) | Un seul mail regroupé pour les 12 machines, puis un mail de résolution |
| Restauration d’une base depuis l’export SQL (5 novembre) | 12 tables identiques à l’original, 0 différente |
| Copie hors site : premier envoi puis relecture complète (5 novembre) | 14 machines, 66,8 Gio relus depuis le stockage distant, 0 erreur |
| Alertes de la copie hors site (11 et 12 novembre) | Une cause réelle par règle : seuil d’âge abaissé, stockage rendu injoignable, machine sauvegardée sans copie ; chaque fois un mail d’alerte, puis un mail de résolution |
| Restauration d’une machine depuis la copie hors site (6 novembre) | 32 Gio en 125 s ; la machine démarre, site et données présents |
Figure 4 · La copie hors site relue en entier : 14 machines, 0 erreur (5 novembre 2026).
Figure 5 · Une machine restaurée depuis la copie hors site, en 125 s (6 novembre 2026).
Bilan critique
Ce qui a coincé. La machine du serveur PBS, placée dans le pool, faisait échouer la tâche chaque nuit : elle essayait de se sauvegarder elle-même. Sortie du pool, la nuit suivante a réussi. Le déplacement des disques a obligé à redémarrer le cluster de bases à froid, dans l’ordre que décrit mon mode opératoire. Les notifications ont d’abord échoué : le port 25 était bloqué, il fallait le port 587 avec STARTTLS, et le routage par défaut de PBS continuait d’essayer le port 25 jusqu’à ce que je le désactive.
Les machines Windows grossissaient la sauvegarde (jusqu’à 23 Gio écrits par jour sur le poste) : des tâches planifiées de Windows, à identifier une par une. Et une première restauration a été interrompue trop tôt par impatience : la seconde a été attendue jusqu’au bout.
Les limites que j’assume.
- La variante 3-2-1-1-0 demande en plus une copie hors ligne ou immuable : ma copie hors site est en ligne, et quiconque a la clé peut l’effacer. C’est le maillon qui manque. Je l’ai étudié : PBS ne gère pas le verrouillage des objets sur un stockage S3, parce que sa déduplication réutilise d’anciens blocs et que son ménage doit pouvoir effacer. Des instantanés en lecture seule du stockage hors site, hors de portée des clés, le permettraient, mais ce stockage n’a pas la place de garder plus de copies : risque accepté, écrit dans la documentation du laboratoire.
- Une partie de la restauration depuis la copie hors site a pu être servie par le cache local de PBS ; la relecture complète depuis le stockage distant, elle, est prouvée. Le cas « serveur PBS perdu » (nouveau PBS, cache vide) reste un exercice à faire.
- Le stockage hors site est joignable depuis tout Internet, protégé par ses clés et par HTTPS : risque accepté.
- Sept jours de rétention sur le laboratoire, trois copies hors site : suffisant pour un laboratoire, court pour une entreprise.
Ce que je referais autrement. Je sortirais la machine du serveur de sauvegarde du pool dès sa création, et je séparerais les disques des machines de leurs sauvegardes avant la première nuit, au lieu de le découvrir à la lecture du premier journal.
Outils et aides. Les choix et les décisions sont les miens, ainsi que les étapes écrites à la première personne. Un assistant IA (Claude Code) a exécuté une partie des commandes et m’a aidé à rédiger la documentation, que j’ai relue.