Échec silencieux de sauvegarde : quand les logs OK mentent
Le défi
Une demande de restauration vient d'échouer : l'archive de base de données de la semaine dernière ne contient rien. Le job nocturne a signalé OK toutes les nuits et le tableau de bord est resté au vert, donc personne n'a rien vu. Connectez-vous à l'hôte de sauvegarde, déduisez de cron où le job écrit son journal, et lisez ce journal nuit par nuit. Une nuit porte un avertissement qui s'est résolu tout seul, et ce n'est pas ce que vous cherchez. Vous voulez la première nuit où l'archive est sortie vide alors que le job se déclarait encore en succès. Soumettez cette date au format AAAA-MM-JJ.
Ce que tu vas apprendre
- Suivre un job planifié depuis son entrée cron jusqu'au fichier journal qu'il écrit
- Lire un journal pour la valeur de sa sortie plutôt que pour son mot de statut
- Reconnaître l'échec silencieux, où un job réussit tout en ne produisant rien
- Distinguer un avertissement passager du véritable point de rupture
- Relier une modification de configuration à la première nuit où son effet est apparu
Compétences testées
Prérequis
- Navigation de base en shell avec cd, ls et cat
- Connaissance du format de planification cron
Comment ça marche
Les échecs de sauvegarde les plus coûteux sont les silencieux. Un job qui plante est remarqué en une journée, parce que quelque chose passe au rouge. Un job qui se termine proprement tout en produisant une archive vide peut tourner pendant des mois, et vous ne le découvrez qu'au pire moment possible : pendant une restauration.
Cet hôte illustre exactement ce schéma. /etc/cron.d/backup exécute /opt/backup/run.sh chaque nuit à 02:30 et ajoute sa sortie à /var/log/backup.log. Chaque ligne de ce journal commence par OK, parce que run.sh affiche OK inconditionnellement. Il mesure l'archive avec du et compte les entrées avec tar tzf, puis rapporte les deux nombres, mais ne les compare jamais à rien. tar se termine avec le code 0 lorsqu'il archive avec succès zéro fichier, donc rien ne déclenche d'alerte pour le script ou le tableau de bord.
La preuve ne se trouve donc pas dans le mot de statut mais dans les chiffres à côté. Jusqu'au 2026-08-16, chaque nuit écrit environ 430M sur environ 129000 fichiers. À partir du 2026-08-17, chaque nuit écrit size=0 files=0 dur=0m tout en indiquant toujours OK. La cause est une modification dans /opt/backup/exclude.list datée du 2026-08-16, qui a ajouté le motif /* pour ignorer un nouveau point de montage temporaire. Ce motif correspond à tout, donc l'exécution suivante, le 17, n'a rien archivé.
Erreurs fréquentes
- Répondre 2026-08-14 à cause de l'avertissement. Cette nuit-là a enregistré un espace disque faible, mais elle a tout de même produit une archive de 427M. Un avertissement qui se résout n'est pas la rupture.
- Filtrer le journal pour des erreurs. Il n'y en a aucune. Chercher ERROR ou FAIL avec grep ne renvoie rien et renforce la fausse conclusion que le job est sain.
- Répondre la date de la restauration échouée. La restauration a échoué plus tard ; la question demande quand les archives sont devenues vides pour la première fois.
- Répondre 2026-08-16. C'est la date à laquelle la liste d'exclusion a été modifiée et la dernière nuit saine. La première archive vide est l'exécution suivante, le 17.
- S'arrêter au journal pivoté.
backup.log.1couvre fin juillet jusqu'au 2026-08-07 et est entièrement sain ; la rupture se trouve dans lebackup.logactuel.
Comment s'en protéger
Une sauvegarde n'est réelle que si elle est vérifiée. Surveillez la sortie d'un job, pas le fait qu'il se soit exécuté, et prouvez la capacité de restauration selon un calendrier plutôt que de la supposer.
- Alertez sur la taille de sortie absolue et relative : faites échouer l'exécution si l'archive est sous un seuil plancher, ou si elle s'écarte fortement de la moyenne des exécutions précédentes.
- Faites échouer le job lui-même. Faites en sorte que
run.shvérifie le nombre de fichiers et sorte avec un code non nul quand il est nul, afin que cron et le tableau de bord voient un véritable échec. - Exécutez des tests de restauration automatisés. Décompressez périodiquement l'archive la plus récente dans un emplacement temporaire et vérifiez que les chemins attendus existent.
- Traitez les motifs d'exclusion comme une entrée dangereuse. Passez-les en revue dans la gestion des changements et rejetez les jokers non ancrés comme
/*. - Alertez aussi sur l'absence de signal, afin qu'un job qui cesse complètement de journaliser soit aussi visible qu'un job qui journalise une erreur.