Alerte quand votre sauvegarde ne tourne plus — avant d'en avoir besoin
Dernière mise à jour : juillet 2026 · Par Yohann Kipfer, Cron-Ping
La panne de sauvegarde dangereuse, ce n'est pas « le dump a échoué ». C'est « le dump n'a même jamais démarré — pendant des semaines — et personne ne le savait ». Un disque plein, une clé SSH expirée, une crontab effacée par une reconstruction de serveur : la sauvegarde s'arrête en silence, et vous le découvrez le jour où vous tentez de restaurer. Ajoutez un ping qui ne part que si la sauvegarde réussit, et laissez son absence vous alerter :
0 2 * * * /opt/backup.sh && curl -fsS https://cron-ping.com/p/TOKENLe && est toute l'astuce : curl ne s'exécute que si backup.sh sort en 0. Si le script échoue ou ne tourne jamais, aucun ping n'atteint Cron-Ping, et une fois le délai de grâce passé vous recevez un mail. Une sauvegarde non surveillée n'est pas une sauvegarde — c'est un espoir.
Le scénario cauchemar, c'est le silence, pas l'erreur
La plupart des équipes qui perdent des données n'avaient pas « aucune sauvegarde ». Elles avaient des sauvegardes cassées en silence depuis des mois. La chaîne classique : le disque de destination se remplit, ou la clé SSH vers l'offsite expire, ou une reconstruction de serveur fait sauter la ligne de crontab — et le job de nuit soit part en erreur dans /dev/null, soit ne se déclenche jamais. Tout paraît normal. Les dashboards sont verts. Puis un disque meurt, on lance la restauration, et la copie exploitable la plus récente date d'avant le début du problème.
Un moniteur ne fait pas les sauvegardes ; il rend leur absence bruyante. C'est la moitié manquante de tout script de backup.
Pinguer au succès — une ligne par outil
Chaînez le ping avec && pour qu'il ne parte que sur une sortie propre (code 0). Voici le motif pour les outils courants :
| Outil | Ligne |
|---|---|
| mysqldump | mysqldump --single-transaction db | gzip > d.sql.gz && curl -fsS …/p/TOKEN |
| pg_dump | pg_dump -Fc db > d.dump && curl -fsS …/p/TOKEN |
| rsync | rsync -a /data/ backup:/srv/ && curl -fsS …/p/TOKEN |
| borg | borg create ::'{now}' /data && curl -fsS …/p/TOKEN |
| restic | restic backup /data && curl -fsS …/p/TOKEN |
curl -fsS est volontaire : -f échoue sur une erreur HTTP, -s reste silencieux, -S affiche quand même une erreur en cas de souci — le curl lui-même ne peut donc pas échouer en douce. Donnez au check Cron-Ping la même période que la sauvegarde (quotidienne → 1 jour, hebdo → 7 jours) et une grâce assez large pour couvrir une nuit lente sans masquer une exécution vraiment manquée.
Un code de sortie propre n'est pas une bonne sauvegarde — vérifiez la taille
mysqldump peut sortir en 0 et vous rendre un dump cassé. Deux pièges réels : avec --force, il continue après une erreur de table et sort quand même en 0 ; et un dump interrompu par une connexion qui tombe peut laisser un fichier tronqué avec un code 0 si le buffering le cache. La parade : vérifier l'artefact, pas seulement le code de sortie — et envoyer /fail quand il est vide :
#!/bin/bash
set -o pipefail
OUT=/backup/db-$(date +%F).sql.gz
mysqldump --single-transaction --quick app | gzip > "$OUT"
# une vraie sauvegarde ne fait jamais quelques octets — 0 ou minuscule = échec
if [ -s "$OUT" ] && [ "$(stat -c%s "$OUT")" -gt 1024 ]; then
curl -fsS https://cron-ping.com/p/TOKEN
else
curl -fsS https://cron-ping.com/p/TOKEN/fail
fiset -o pipefail compte ici : sans lui, mysqldump | gzip renvoie le code de gzip, donc un dump échoué envoyé dans un gzip réussi ressemble à un succès. Avec pipefail, le pipeline échoue si n'importe quelle étape échoue.
Mesurez l'exécution, et lisez les codes de sortie de l'outil
Pinguez /start en tête et /success à la fin, et Cron-Ping enregistre la *durée*. Un pg_dump de nuit passé de 4 à 40 minutes vous dit que la base a grossi — utile bien avant que ça devienne un job planté à 3 h du matin. Et borg comme restic ont des codes de sortie plus riches que 0/1, sur lesquels il vaut la peine de brancher :
| Code | borg | restic |
|---|---|---|
| 0 | succès | succès |
| 1 | avertissement (terminé avec des warnings) | erreur générale — sauvegarde échouée |
| 2 | erreur — sauvegarde échouée | erreur runtime Go |
| 3 | — | certains fichiers source illisibles (sauvegarde partielle) |
Un borg en 1 (warning) ou un restic en 3 (partiel), c'est exactement l'état « a tourné, mais pas vraiment » qu'un simple && compterait comme succès. Branchez sur le code et envoyez /fail pour qu'une sauvegarde partielle ne se fasse pas passer pour une bonne.
Le reste de l'assurance : 3-2-1, chiffrement, et tester la restauration
- *Appliquez le 3-2-1. Trois copies des données, sur deux supports différents, dont une hors site. Un dump de nuit surveillé qui vit sur le même disque que la base ne satisfait aucun* des trois quand ce disque meurt.
- *Testez la restauration, régulièrement. Une sauvegarde jamais restaurée est une théorie. Restaurez périodiquement dans un conteneur jetable et vérifiez des comptes de lignes ou un enregistrement connu. Enveloppez ce* job dans son propre check Cron-Ping — pour que « personne n'a testé la restauration depuis 90 jours » devienne une alerte.
- *Chiffrez les copies hors site.*
resticetborgchiffrent par défaut ; unmysqldumpbrut rsyncé hors site, non. Un dump de base non chiffré sur le stockage d'un tiers est une fuite en attente. - *Surveillez la rétention. Une règle de rétention trop agressive peut effacer la dernière bonne copie juste après une mauvaise exécution. Gardez assez d'historique pour pouvoir remonter avant* le moment où une panne silencieuse a commencé.
FAQ
Comment être alerté si ma sauvegarde ne tourne plus ?
Ajoutez && curl -fsS https://cron-ping.com/p/TOKEN à la fin de la commande de sauvegarde et créez un check dont la période correspond à l'horaire. Le ping ne part que sur une sauvegarde réussie ; si elle échoue ou ne tourne jamais, aucun ping n'arrive, et une fois le délai de grâce écoulé Cron-Ping vous alerte par e-mail ou Slack. Ça couvre le cas que les outils internes ne voient pas : un job qui n'a jamais démarré.
Mon script sort en 0 mais le dump est vide — comment l'attraper ?
Vérifiez l'artefact, pas seulement le code de sortie. Testez la taille du fichier ([ -s fichier ] et un minimum d'octets) avant de pinguer le succès, et tapez l'endpoint /fail s'il est trop petit. Utilisez aussi set -o pipefail pour qu'un mysqldump | gzip échoué ne fasse pas passer le succès de gzip pour celui de tout le pipeline.
Quelle période et quelle grâce pour une sauvegarde de nuit ?
Période = 1 jour pour un job quotidien, 7 jours pour un hebdomadaire. La grâce doit couvrir la durée d'une exécution normale plus un peu de marge — si le dump prend d'habitude 20 minutes, une grâce d'1 à 2 heures absorbe une nuit lente sans masquer une exécution qui n'a vraiment pas eu lieu. Pour une sauvegarde hebdo, une grâce de plusieurs heures à un jour est raisonnable.
Ça marche avec restic et borg ?
Oui. Chaînez le ping après restic backup ou borg create. Mieux : branchez sur leurs codes de sortie. Un borg en 1 (warning) ou un restic en 3 (certains fichiers illisibles) est une sauvegarde partielle qu'il faut traiter comme un échec et envoyer sur /fail, pas compter comme verte.
Un log de sauvegarde vert ne suffit-il pas ?
Non — un log n'existe que si le job a tourné, et encore faut-il le lire. Les pannes qui coûtent des données sont celles où le job s'est arrêté en silence : crontab effacée, disque plein, clé expirée. Il n'y a aucun log d'erreur pour un job qui ne s'est jamais déclenché. Un heartbeat manquant est le seul signal qui vous atteint sans que vous ayez à regarder.
Recevez un mail le jour où votre sauvegarde s'arrête — pas le jour où vous en avez besoin
Ajoutez un && curl à votre script de sauvegarde et réglez un check sur son horaire. Si le dump échoue, sort vide, ou ne démarre jamais, le ping n'arrive pas et Cron-Ping vous alerte — pendant qu'il reste encore une bonne copie sur laquelle se rabattre.
Plan gratuit : 10 checks, alertes email, historique 7 jours. Sans carte. Hébergé en UE.