Politique de sauvegarde et test de restauration avec Proxmox Backup Server
Mise en place d'une politique de sauvegarde complète sur Proxmox Backup Server — rétention, vérification d'intégrité, moindre privilège — validée par une restauration intégrale sur machine isolée.
Preuves sélectionnées
4 / sélection éditoriale
Le contexte
Une infrastructure de neuf machines virtuelles représentant plusieurs semaines de configuration : un domaine Active Directory, un serveur de fichiers avec sa structure de droits, une plateforme de supervision, un serveur de déploiement. Aucune sauvegarde.
Le risque n'était pas théorique — c'est précisément sur ce type d'environnement qu'on teste des configurations et qu'on casse des choses.
L'objectif
Mettre en place une sauvegarde qui réponde à trois exigences, dans cet ordre :
- Automatique — une sauvegarde qui dépend d'une action humaine n'existe pas ;
- Vérifiée — une sauvegarde qu'on n'a jamais relue n'est pas une sauvegarde, c'est une hypothèse ;
- Restaurée au moins une fois — sinon on ne sauvegarde pas, on collectionne des fichiers.
Le troisième point était l'objectif réel du projet. Les deux premiers, tout le monde les fait.
Les choix techniques
Proxmox Backup Server plutôt que l'export intégré de Proxmox VE. L'export produit une archive complète à chaque exécution. PBS travaille en déduplication par blocs : seuls les blocs modifiés depuis la sauvegarde précédente sont transférés et stockés. Sur des machines Windows dont l'essentiel du disque ne bouge pas, la différence de volume et de durée est considérable.
Il apporte aussi ce que l'export n'a pas : vérification d'intégrité, politique de rétention native et restauration granulaire de fichiers individuels sans restaurer la machine entière.
Un serveur dédié, avec deux disques séparés. Un petit disque système, un grand disque dédié au datastore — ce dernier explicitement exclu des sauvegardes, pour ne pas sauvegarder les sauvegardes.
Ce que j'ai réalisé
Le serveur
Installation de Proxmox Backup Server 4.2, bascule sur le dépôt sans souscription, formatage du disque de données en ext4 et création du datastore.
Le moindre privilège
Point sur lequel j'ai été volontairement strict. L'hyperviseur ne se connecte pas en administrateur sur le serveur de sauvegarde. Un compte de service dédié a été créé, avec le rôle DatastoreBackup — le minimum permettant d'écrire des sauvegardes — et cette permission est appliquée sur le seul datastore concerné, pas à la racine.
Pourquoi ce niveau de détail ? Un rançongiciel qui compromet l'hyperviseur récupère les identifiants qu'il utilise. Si ces identifiants sont administrateurs sur le serveur de sauvegarde, il efface les sauvegardes avant de chiffrer les machines. Avec un rôle limité à l'écriture, il peut ajouter des sauvegardes ; il ne peut pas supprimer les précédentes.
Le raccordement entre l'hyperviseur et le serveur de sauvegarde utilise l'empreinte du certificat, ce qui authentifie le serveur distant.
La planification
Sauvegarde quotidienne à 02:00, portant sur toutes les machines de l'infrastructure.
Deux exclusions, chacune pour une raison précise :
- Le serveur de sauvegarde lui-même. PBS ne peut pas figer son propre système de fichiers via l'agent QEMU pendant qu'il écrit dans son datastore — c'est un blocage circulaire. La sauvegarde du serveur PBS relève d'une autre méthode : c'est sa configuration qu'on sauvegarde, pas la machine.
- Une machine temporaire issue d'un test de restauration, sans valeur à conserver.
Rétention 7 / 4 / 3 — sept sauvegardes quotidiennes, quatre hebdomadaires, trois mensuelles. Cette dégressivité couvre trois besoins distincts : l'erreur détectée le jour même, celle détectée dans le mois, et le retour à un état antérieur plus lointain — le tout sans conserver quatre-vingt-dix copies.
Détail d'exploitation : la rétention est configurée côté serveur de sauvegarde, pas côté hyperviseur. Le compte de service ne dispose volontairement pas du droit d'élagage, ce qui provoquait une erreur de permission à chaque tâche. La suppression est donc pilotée par le serveur qui détient les données — ce qui est aussi le comportement le plus sain : la machine sauvegardée n'a pas à décider de la destruction de ses propres sauvegardes.
Deux tâches de maintenance hebdomadaires :
- Garbage collection le samedi — libère l'espace des blocs qui ne sont plus référencés par aucune sauvegarde ;
- Vérification d'intégrité le dimanche — relit les données et compare les sommes de contrôle, avec re-vérification des sauvegardes de plus de 30 jours.
C'est cette seconde tâche qui distingue une sauvegarde d'une archive : elle détecte une corruption silencieuse avant qu'on en ait besoin.
Le test de restauration
La partie qui donne du sens à tout le reste.
Le serveur de fichiers a été restauré sous un nouvel identifiant de machine, sur une machine isolée du réseau. Deux précautions liées : ne pas écraser la machine d'origine, et éviter tout conflit avec le domaine — une machine restaurée qui redémarre sur le réseau avec la même identité que l'originale crée des problèmes d'authentification.
Le protocole de vérification a été défini avant la restauration, avec un fichier témoin déposé sur le serveur d'origine juste avant la sauvegarde.
Résultats :
| Vérification | Résultat |
|---|---|
| Fichier témoin | Présent |
| Arborescence du volume de données | Intacte |
| Partages SMB | Les quatre présents avec leurs propriétés |
| Permissions NTFS | Conservées |
Les identifiants de sécurité apparaissaient sous forme brute plutôt que traduits en noms de groupes — comportement normal et attendu : la machine était déconnectée du réseau et ne pouvait donc pas interroger le contrôleur de domaine pour effectuer la traduction. Le fait de savoir prévoir cette observation faisait partie du test.
Le résultat
Une politique de sauvegarde complète et documentée : automatisée, avec une rétention raisonnée, une vérification d'intégrité planifiée, un compte de service limité au strict nécessaire — et une restauration réellement effectuée et vérifiée point par point.
Ce que j'en retiens
Toute la valeur du projet tient dans la dernière étape. Configurer une sauvegarde prend une heure ; la restaurer prend une demi-journée, et c'est la seule des deux qui apporte une certitude.
Et la contrainte la plus instructive n'était pas technique mais logique : un système de sauvegarde ne peut pas se sauvegarder lui-même. Comprendre pourquoi, c'est comprendre ce qu'est réellement un point de reprise.