Ta sauvegarde annonce un succès : comment sais-tu que c'est vrai ?
En bref
Un rapport de sauvegarde dit qu'une tâche s'est exécutée, pas que les données sont utilisables. Les sauvegardes s'arrêtent en silence, et le rapport reste vert ou cesse d'arriver, ce que personne ne remarque. Deux contrôles règlent l'essentiel : la tâche s'annonce quand elle se termine, et tu surveilles l'âge de la dernière bonne sauvegarde.
Presque toutes les entreprises ont des sauvegardes. Moins nombreuses sont celles qui ont une copie capable de les remettre debout demain matin. L’écart vient rarement du logiciel de sauvegarde : il vient de ce qu’une sauvegarde qui cesse de fonctionner le fait sans bruit, et que le silence ressemble à tout va bien.
Que prouve vraiment un rapport de sauvegarde réussie ?
Il prouve qu’une tâche s’est exécutée. Il ne prouve pas que les fichiers sont complets, que la destination avait de la place, que la clé de chiffrement est disponible, ni que quelqu’un pourrait restaurer à partir de là.
Chez les professionnels de l’informatique, les histoires sont presque interchangeables, et ce sont les durées qui font mal : un mois sans une seule bonne sauvegarde parce que les alertes partaient vers la boîte mail de quelqu’un qui avait quitté l’entreprise ; un ensemble de sauvegardes découvert corrompu depuis environ quatre mois, trouvé au moment de la restauration ; des bandes vides parce que la tâche n’avait en réalité jamais été programmée.
Aucun de ces systèmes n’appelait à l’aide. Chacun avait l’air normal jusqu’au jour où quelqu’un a eu besoin des données.
Quels deux contrôles attrapent presque tout ?
Deux : la tâche qui s’annonce quand elle a fini, et un chiffre qui dit l’âge de la dernière sauvegarde valable.
Premier : fais parler la tâche. À la fin de ton script de sauvegarde, fais-lui appeler une URL. Si l’appel n’arrive pas dans la fenêtre attendue, tu reçois une alerte. Ce seul changement retourne le problème : tu ne dépends plus du fait que la panne soit signalée, tu remarques le silence. Cela attrape la tâche qui n’a jamais démarré, la machine qui était éteinte, le service qui a planté, le script mort à mi-chemin.
Deuxième : surveille un chiffre. Fais afficher par une petite commande quelque chose qui compte pour toi — les heures écoulées depuis la dernière sauvegarde réussie, ou la taille du fichier le plus récent — et traite ce chiffre comme une valeur surveillée avec un seuil. Une tâche peut se terminer sans rien écrire ; un chiffre l’attrape, un rapport vert non.
Les deux fonctionnent sur n’importe quel système capable d’exécuter une commande ou de faire un appel HTTP, ce qui inclut presque tous les produits de sauvegarde, scripts ou planificateurs que tu utilises déjà.
Pourquoi le NAS ne peut-il pas te sauver ici ?
Parce qu’il ne sait pas lever une alerte tout seul, et parce qu’il n’expose pas du tout le résultat des tâches de sauvegarde. Le guide MIB de Synology indique lui-même que DSM ne prend pas en charge les traps SNMP : l’appareil ne peut pas envoyer une alerte de lui-même. On peut l’interroger — santé des disques, état RAID y compris dégradé et en panne, espace libre — mais seulement depuis quelque chose d’extérieur, qui l’interroge.
Et le résultat des tâches de sauvegarde elles-mêmes n’est pas exposé du tout. Donc « le NAS me le dira » a deux problèmes : il ne te le dit que si on le lui demande, et il ne te dit jamais rien de la tâche.
Que faire cette semaine
- Ajoute la ligne d’annonce à la fin de la tâche de sauvegarde, et règle la fenêtre attendue.
- Affiche un chiffre — les heures écoulées depuis la dernière bonne sauvegarde — et surveille-le.
- Surveille la destination : espace libre et santé des disques, pour entendre parler d’un volume plein avant que la tâche n’échoue.
- Planifie un test de restauration. Mets-le dans l’agenda avec un nom, pas avec « quelqu’un devrait ».
Une sauvegarde que tu n’as jamais restaurée est un espoir. Une sauvegarde qui te dit chaque matin qu’elle est toujours là, et quel âge elle a, est un système.
Ce que nous ne pouvons pas te dire
- Nous ne pouvons pas lire le résultat d'une tâche de sauvegarde à l'intérieur d'un NAS : les logiciels NAS courants, grand public comme professionnels, ne l'exposent pas sur le réseau, et nous ne prétendrons pas le contraire.
- Nous ne pouvons pas te dire qu'une sauvegarde est restaurable : seul un test de restauration le prouve.
- Nous ne voyons que ce que ton système nous dit : une tâche qui s'annonce, un chiffre que ton script affiche, ou un appareil qui répond.
Les questions qu'on pose vraiment
Pourquoi les sauvegardes échouent-elles en silence au lieu de lever une erreur ?
Parce que la partie qui lèverait l'erreur est souvent celle qui s'est arrêtée. Une tâche planifiée qui ne démarre jamais n'envoie rien. Un service qui a planté n'envoie rien. Une boîte mail qui refuse l'alerte l'avale. Le silence ressemble exactement au succès, et c'est pour cela que tant de pannes durent des mois.
Quel est le contrôle le plus simple qui fonctionne vraiment ?
Faire en sorte que la tâche de sauvegarde s'annonce quand elle se termine, et alerter quand l'annonce n'arrive pas à temps. Cela inverse la logique : au lieu d'attendre une mauvaise nouvelle qui ne partira peut-être jamais, tu remarques le silence. Cela tient en une ligne à la fin du script existant.
Que surveiller à part la tâche elle-même ?
L'âge de la dernière bonne sauvegarde, sous forme de chiffre : les heures écoulées depuis la dernière exécution réussie, ou la taille du fichier de sauvegarde le plus récent. Une tâche peut se terminer et produire un fichier vide. Un chiffre que tu regardes chaque jour l'attrape ; un rapport vert non.
À quelle fréquence faut-il tester une restauration ?
Au moins deux fois par an, sur une machine qui n'est pas celle de production, chronomètre en main. Tu apprends deux choses qu'aucun rapport ne te dira : si les données reviennent, et combien de temps l'entreprise serait à l'arrêt. Note les deux.