Dans mon article précédent, je racontais comment j'ai remplacé des hyperviseurs propriétaires par Proxmox, sans jamais couper la production. Une fois la virtualisation migrée, il restait une dernière pièce propriétaire au cœur de l'infrastructure : le logiciel de sauvegarde. Il protégeait fidèlement une plateforme qui n'existait plus.
Ce deuxième chantier avait l'air plus simple. Il ne l'était pas. Changer d'outil de sauvegarde, ce n'est pas remplacer un logiciel par un autre : c'est déménager une mémoire. Les sauvegardes d'hier doivent rester lisibles demain, alors que le nouvel outil ne sait pas les lire. Voici comment j'ai remplacé Veeam par Proxmox Backup Server sans perdre cinq ans d'historique, et les pièges que personne ne documente.
Pourquoi changer une sauvegarde qui fonctionne ?
Après la migration, la situation était absurde. Les tâches de sauvegarde des machines virtuelles tournaient dans le vide : leurs sources avaient déménagé sur Proxmox. Et sur Proxmox, Proxmox Backup Server (PBS) sauvegardait déjà toutes les machines et tous les conteneurs chaque nuit, chiffrés, incrémentaux et dédupliqués.
Deux outils, deux consoles, deux licences, deux façons de tomber en panne sans prévenir. L'ancien n'apportait plus que deux choses que PBS ne fait pas tout seul : la sauvegarde des partages de fichiers d'un NAS, et un historique de plusieurs années, enfermé dans son format propriétaire.
Les raisons de passer à l'open-source étaient les mêmes que pour les hyperviseurs : le coût, l'indépendance vis-à-vis d'un éditeur, et surtout la lisibilité. Une configuration PBS, ce sont des fichiers texte. Mon agent IA peut les lire, les auditer, les comparer à la documentation. Une console propriétaire, il ne peut que la regarder de loin.
Première question : que perdrait-on en coupant aujourd'hui ?
Avant de toucher à quoi que ce soit, j'ai dressé la liste de chaque tâche de l'ancien outil, avec en face son équivalent dans PBS et son niveau de couverture. Pas une liste de souhaits : un relevé fait sur le système vivant.
- Les machines virtuelles. Déjà dans PBS depuis la migration. Les anciennes tâches pouvaient s'arrêter sans rien perdre.
- Les partages de fichiers. Aucun équivalent : PBS ne sauvegarde nativement que des machines Proxmox. J'ai donc créé un petit conteneur dédié qui monte les partages en lecture seule et les envoie à PBS avec son client en ligne de commande, partage par partage, chiffrés avec une clé à part. Même déduplication, même rétention, même supervision que tout le reste.
- L'historique. C'est là que tout se joue. Aucun outil open-source ne lit le format de l'ancien logiciel. Migrer vers PBS ne convertit rien du passé.
La porte : prouver qu'on sait restaurer, avant de couper
Ma règle sur ce chantier : aucune étape irréversible sans une preuve. La première était évidente : savoir restaurer depuis PBS, pour les deux types de données.
Pour les machines, j'ai restauré un conteneur depuis une sauvegarde chiffrée vers une copie isolée, sans carte réseau et sans démarrage automatique, pour ne jamais entrer en conflit avec l'original. Il a démarré, et ses données étaient identiques à l'octet près. Puis la copie a été détruite. Pour les fichiers, j'ai extrait un seul fichier d'une archive chiffrée, avec sa clé dédiée, et vérifié son contenu.
Ensuite seulement, j'ai désactivé les tâches de l'ancien outil. Désactivé, pas supprimé : la configuration et les points de restauration restaient intacts, et une commande suffisait à tout réactiver. Bonus inattendu : ses données étaient désormais figées, une cible stable pour la suite.
Le vrai sujet : cinq ans d'historique que personne ne sait relire
Le plus ancien point de restauration datait de septembre 2021. Cinq ans d'historique, et un détail qui change tout : l'essentiel n'existait qu'à un seul endroit, le stockage du serveur de sauvegarde lui-même. Le serveur que je voulais justement réutiliser. Avant de l'effacer, il fallait sortir cet historique et m'assurer qu'il resterait lisible pendant des années. Trois découvertes ont changé le plan.
Un volume plus grand que lui-même
Le stockage de l'ancien outil annonçait 10,9 To occupés. La somme des dossiers faisait 14,8 To. L'écart vient du clonage de blocs du système de fichiers ReFS : pour fabriquer ses sauvegardes complètes synthétiques, le logiciel partage des blocs entre fichiers au lieu de les dupliquer. À la copie, chaque fichier reprend sa taille réelle. Dimensionner la cible sur 11 To aurait échoué aux trois quarts du chemin. Il fallait 15 To.
Un fichier de cinq ans, relu sans licence
Le pire scénario d'un historique propriétaire, c'est de garder des sauvegardes qu'on ne sait plus ouvrir. J'ai donc testé sur la plus ancienne : un fichier de sauvegarde de septembre 2021, ouvert avec l'outil d'extraction autonome de l'éditeur, sans licence, sans installation complète, sans mot de passe. Onze minutes plus tard, j'avais les disques de la machine au format VHDX, un format ouvert, montable directement ou convertible pour Proxmox.
Mais cet outil ne lit que les sauvegardes de machines. Ni celles des partages de fichiers, ni celles des agents.
Garder un lecteur, pas une infrastructure
Pour relire tout le reste, il faut une installation de l'ancien logiciel. Plutôt que de la réinstaller sur un vieux serveur de récupération, qui aurait eu plus de vingt ans au bout de la période de conservation, j'ai converti le serveur physique en machine virtuelle. Elle reste éteinte, ne démarre que pour une relecture, est elle-même sauvegardée par PBS, et surtout elle conserve la base de configuration de l'ancien outil : l'index de toutes les tâches et de tous les points de restauration. Une réinstallation propre l'aurait perdu.
Convertir un serveur physique en VM du premier coup
La conversion a démarré du premier coup : pas d'écran bleu, pas de mode récupération, pas de clé BitLocker réclamée. Ce n'était pas de la chance, c'était une liste.
- Capturer le système, pas les données. L'outil de capture coche tous les volumes par défaut. Tout décocher d'abord, sinon on embarque des dizaines de téraoctets de sauvegardes : la sélection devait totaliser 134 Go. Et ne jamais écrire l'image sur un volume qu'on est en train de capturer.
- Le bon contrôleur de disque. L'image ne contient aucun pilote VirtIO : le disque est attaché en SATA, sinon Windows ne voit pas son propre système.
- Le bon micrologiciel. Le disque d'origine est en GPT : démarrage UEFI (OVMF) sur une machine q35, sans clés Secure Boot préinscrites.
- BitLocker vérifié avant, pas après. Un volume scellé à la puce TPM du serveur d'origine aurait réclamé sa clé de récupération au premier démarrage.
L'import a lu 223,5 Gio et n'en a écrit que 127 : les zones vides ne sont pas recopiées. Premier démarrage en moins d'une minute, réseau coupé, puis tous les services de l'ancien outil passés en démarrage manuel. Un lecteur d'archives n'a pas besoin de tourner.
Deux disques, deux empreintes, et un piège
L'historique est parti sur deux disques externes de 18 To, rangés dans deux lieux différents. Chaque fichier a son empreinte SHA-256 dans un manifeste : près de 150 000 fichiers, 11,5 Tio. Rien n'est considéré comme copié tant que la relecture n'a pas comparé chaque empreinte, puis les deux disques ont été validés l'un contre l'autre.
Deux enseignements au passage. Mon estimation de durée était pessimiste d'un facteur deux : je l'avais calculée sur un échantillon de quelques minutes à 42 Mo/s, alors que le régime établi tenait 81 Mo/s. Sur une copie USB, un échantillon court ne dit rien. Et les dossiers remplis de petits fichiers allaient sept fois moins vite que les autres : la pénalité vient du nombre de fichiers, pas du lien.
Et le piège. En comparant les deux manifestes, une différence est apparue : un dossier avait perdu une semaine de points de restauration entre la première et la seconde copie. La cause : la rétention de l'ancien logiciel. Elle tournait chaque nuit, indépendamment des tâches, même désactivées. Désactiver les sauvegardes ne fige pas la rétention. L'historique long, lui, était intact sur les deux disques, et la semaine manquante restait sur le premier. Sans les empreintes, je ne l'aurais jamais vu.
Réemployer le serveur : un RAID de 37 To devient un PBS
La porte suivante était la plus importante du chantier : relire l'archive depuis les disques externes, avant tout effacement. Une fois passée, le serveur de l'ancien outil pouvait renaître.
Contrôleur RAID en mode JBOD, pour que ZFS voie les disques bruts. Deux groupes RAIDZ2 de six disques, environ 29 Tio utiles, compression lz4, et pas de déduplication ZFS : PBS déduplique déjà par blocs, la doubler ne coûterait que de la mémoire. Pourquoi deux groupes de six plutôt qu'un de douze ? Les disques avaient cinq ans : une reconstruction deux fois plus rapide, et davantage d'opérations disque pour le ramasse-miettes et les vérifications de PBS, qui lisent beaucoup.
Puis la synchronisation de tout l'existant depuis l'ancien PBS : 633 sauvegardes. Une règle de conception : une synchronisation de plusieurs dizaines d'heures ne croise jamais la fenêtre de sauvegarde. Elle tourne de jour, et une minuterie l'interrompt avant la nuit. Elle reprend le lendemain là où elle s'était arrêtée.
Petit piège au passage : la règle de notification par défaut de PBS envoie un courriel pour chaque synchronisation réussie. Vingt courriels en une journée, et la vraie alerte noyée dans le bruit. Je l'ai remplacée par une règle qui ne parle qu'en cas d'erreur ou d'avertissement.
La bascule a pris 45 minutes, hors de toute fenêtre de sauvegarde : repointer les stockages des hyperviseurs et le conteneur des fichiers vers le nouveau serveur, avec sa nouvelle empreinte TLS. Puis un vrai test : une sauvegarde incrémentale en 11 secondes, 95,7 % des données réutilisées depuis l'historique copié, et une restauration réussie depuis la sauvegarde la plus récente comme depuis la plus ancienne.
La première nuit, et le client oublié
Le lendemain matin, toutes les sauvegardes de machines étaient passées, et la fenêtre de nuit se terminait vers 3 h 15 au lieu de 4 h. Une seule chose manquait, et c'est l'alerte de fraîcheur qui l'a trouvée : un script qui sauvegarde la configuration d'un hyperviseur visait encore l'ancien serveur.
La cause tenait en un mot : head. Mon inventaire des clients passait par un affichage tronqué, et deux lignes manquaient. La bonne méthode, que j'applique désormais à toute bascule : après la première nuit, lister tous les groupes de sauvegarde du nouveau serveur, et exiger pour chacun soit une sauvegarde postérieure à la bascule, soit une raison écrite.
Deux réglages ont fini le travail :
- La détection des changements par métadonnées. Au lieu de relire chaque fichier, le client PBS compare les métadonnées et ne relit que ce qui a changé. Le plus gros partage est passé de 28 à 11 minutes, un autre de 8 à 2, les plus petits se comptent en secondes. Attention : la première passe réécrit tout dans un nouveau format, à planifier hors production. Et ce n'est pas une règle universelle : sur un partage de plusieurs centaines de milliers de petits fichiers, le parcours des métadonnées est limité par le processeur du client et devient plus lent que le mode classique. Celui-là y reste. Le bon mode dépend des données, pas du principe.
- Des seuils d'alerte mesurés, pas devinés. L'âge d'une sauvegarde se compte depuis le début de la précédente : une sauvegarde longue dépasse 25 heures avant que la suivante soit finie, et l'alerte sonnait chaque matin pour rien. J'ai mesuré le maximum réel sur sept jours, puis fixé 27 heures pour les machines et 32 heures pour les fichiers. Les vrais échecs restent détectés.
Le bilan
Le vrai gain, comme pour les hyperviseurs, n'est pas la licence. C'est que la sauvegarde est devenue du texte : ses tâches, ses alertes et ses scripts sont versionnés et documentés, et mon agent IA a pu tout lire, mesurer et vérifier avec moi. Les décisions irréversibles, effacer un RAID ou détruire un ancien point de restauration, sont restées les miennes, une par une, après chaque preuve.
Si je devais résumer ce chantier en une règle : on ne migre pas une sauvegarde, on migre une capacité de restaurer. Tant qu'elle n'est pas prouvée, rien n'est fait.
Pour aller plus loin : l'article Hyper-V vers Proxmox, qui précède ce chantier, et Backups anti-ransomware, sur la défense de ces sauvegardes.