DevThis a mis en place et exploite une infrastructure virtualisée sous Proxmox, sauvegardée par Proxmox Backup Server. Au cours de cette exploitation, une revue a révélé que les sauvegardes d’un service échouaient depuis huit jours sans que rien ne le signale. Ce cas d’école illustre une réalité simple : une sauvegarde que personne ne vérifie ne protège de rien.
L’organisation accompagnée n’est pas identifiée ici.
Contexte
L’infrastructure repose sur deux serveurs de virtualisation Proxmox qui hébergent des machines virtuelles et des conteneurs, et sur un serveur de sauvegarde dédié. Les sauvegardes sont automatiques, nocturnes et couvrent l’ensemble des services.
Sur le papier, tout était en place : les tâches étaient planifiées, le serveur de sauvegarde fonctionnait et aucune erreur n’apparaissait au quotidien.
Ce que la revue a révélé
Une revue complète de l’infrastructure a mis au jour trois problèmes qu’aucun utilisateur n’avait remarqués :
- Huit jours de sauvegardes en échec : un instantané resté bloqué sur un conteneur empêchait toute nouvelle sauvegarde de ce service. L’échec se répétait chaque nuit, sans alerte. En cas de panne, la dernière copie exploitable aurait eu plus d’une semaine.
- Un serveur saturé : l’espace de stockage de l’un des deux serveurs était plein à 100 %, ce qui menaçait la stabilité de tous les services qu’il hébergeait.
- Un service arrêté par une mise à jour : un script de mise à jour tiers avait interrompu un service, sans que l’arrêt soit signalé.
Aucun de ces problèmes n’était visible tant que tout continuait à fonctionner. C’est précisément le risque : on découvre qu’une sauvegarde manque le jour où l’on en a besoin.
Interventions réalisées
- Remise en état : suppression de l’instantané bloquant et relance des sauvegardes du service concerné ; libération de l’espace du serveur saturé, ramené de 100 % à 29 % d’occupation ; redémarrage et contrôle du service arrêté.
- Orchestration des sauvegardes : un seul processus pilote les sauvegardes des deux serveurs et rend compte de chaque exécution, réussie ou non.
- Stockage protégé : sauvegardes stockées en miroir sur deux disques, dédupliquées et soumises à une politique de rétention quotidienne, hebdomadaire et mensuelle.
- Serveur de sauvegarde isolé dans le temps : la machine n’est allumée que le temps des sauvegardes, puis s’éteint ; le reste du temps, elle est hors d’atteinte.
- Vérifications régulières : contrôle hebdomadaire de l’intégrité des sauvegardes, vérification mensuelle des disques et surveillance de leur état de santé.
- Restauration testée : une restauration complète a été réalisée et datée, pour s’assurer que les sauvegardes sont réellement exploitables.
- Alertes : notifications envoyées sur une messagerie d’équipe en cas d’échec de sauvegarde ou d’anomalie sur les disques.
- État des lieux daté : chaque affirmation sur l’état de l’infrastructure porte la date de sa dernière vérification ; ce qui n’a pas été revérifié est signalé comme tel.
Résultat
Les sauvegardes couvrent à nouveau l’ensemble des services, leur restauration a été éprouvée et tout échec est désormais signalé dès la nuit où il se produit, au lieu d’être découvert par hasard une semaine plus tard.
La leçon vaut pour toute organisation : mettre en place des sauvegardes ne suffit pas. Il faut aussi les superviser, vérifier qu’elles aboutissent et tester régulièrement qu’on sait les restaurer.
Ce type de vérification fait partie des interventions DevThis pour faire le point sur vos outils et fiabiliser leur exploitation.