Ne découvrez pas l'échec d'un backup lors d'une restauration
Un backup qui n'est jamais vérifié n'est pas un backup. C'est une illusion de sécurité. Trop d'entreprises découvrent que leurs sauvegardes ont échoué au moment précis où elles en ont besoin - lors d'un crash serveur, d'une attaque ransomware, ou d'une erreur humaine catastrophique.
Le scénario cauchemar est classique : le serveur de production tombe. L'équipe technique lance sereinement la restauration depuis le dernier backup. Et là, surprise : le backup date de 3 semaines car le script échouait silencieusement depuis tout ce temps. Ou pire : le fichier existe mais il est corrompu.
Le monitoring heartbeat des backups élimine ce risque. En vérifiant activement que chaque backup s'exécute, réussit, et produit un fichier valide, vous avez la garantie que vos données sont protégées. Et si quelque chose ne va pas, vous le savez immédiatement.
Sans monitoring proactif, de nombreux problèmes peuvent passer inaperçus :
Un backup fiable doit être vérifié à plusieurs niveaux :
Chaque type de backup a ses particularités de monitoring :
MySQL, PostgreSQL, MongoDB - les dumps de bases de données sont critiques. Vérifiez que le dump s'est terminé sans erreur, que le fichier n'est pas vide, et que sa taille est cohérente avec le volume de données. Pour les grosses bases, surveillez aussi la durée d'exécution.
Sauvegardes de répertoires, de configurations, de médias. Utilisez des outils comme rsync ou tar. Vérifiez le nombre de fichiers copiés, la taille totale, et l'absence d'erreurs. Attention aux permissions qui peuvent bloquer certains fichiers.
L'upload vers le cloud peut échouer pour de multiples raisons : credentials expirés, quota dépassé, problème réseau. Vérifiez que le fichier est bien présent dans le bucket et accessible.
Voici un exemple de script bash qui intègre toutes les vérifications recommandées :
#!/bin/bash
# backup_mysql.sh - Backup MySQL avec monitoring complet
HEARTBEAT_URL="https://monitao.com/ping/VOTRE_TOKEN"
BACKUP_DIR="/backups/mysql"
DB_NAME="production"
MIN_SIZE_MB=100 # Taille minimale attendue en Mo
# Ping de démarrage
curl -s "$HEARTBEAT_URL/start" > /dev/null
# Exécution du backup
BACKUP_FILE="$BACKUP_DIR/${DB_NAME}_$(date +%Y%m%d_%H%M%S).sql.gz"
mysqldump -u backup_user -p"$DB_PASSWORD" "$DB_NAME" | gzip > "$BACKUP_FILE" 2>/tmp/backup_error.log
# Vérification 1: Le fichier existe
if [ ! -f "$BACKUP_FILE" ]; then
curl -s "$HEARTBEAT_URL/fail?error=file_not_created" > /dev/null
exit 1
fi
# Vérification 2: La taille est cohérente
FILE_SIZE_MB=$(($(stat -f%z "$BACKUP_FILE" 2>/dev/null || stat -c%s "$BACKUP_FILE") / 1024 / 1024))
if [ "$FILE_SIZE_MB" -lt "$MIN_SIZE_MB" ]; then
curl -s "$HEARTBEAT_URL/fail?error=file_too_small&size=${FILE_SIZE_MB}MB" > /dev/null
exit 1
fi
# Vérification 3: Test d'intégrité gzip
if ! gzip -t "$BACKUP_FILE" 2>/dev/null; then
curl -s "$HEARTBEAT_URL/fail?error=corrupted_gzip" > /dev/null
exit 1
fi
# Tout est OK - ping de succès
curl -s "$HEARTBEAT_URL?size=${FILE_SIZE_MB}MB" > /dev/null
echo "Backup terminé: $BACKUP_FILE (${FILE_SIZE_MB} MB)"Ce script vérifie chaque étape critique : création du fichier, taille minimale, intégrité de la compression. Le ping de succès n'est envoyé que si toutes les vérifications passent.
Voici comment mettre en place le monitoring de vos backups :
Les bonnes alertes vous préviennent au bon moment :
Ces erreurs diminuent l'efficacité de votre monitoring de backup :
Pour les fichiers compressés (gzip, zip), utilisez les outils de vérification intégrés (gzip -t, unzip -t). Pour les dumps SQL, vous pouvez tenter un dry-run de restauration. Pour une vérification complète, calculez un checksum (sha256sum) et stockez-le avec le backup.
Configurez un timeout de 5-6h (durée normale + 50%). Envoyez un ping de démarrage et un ping de fin. Pour les très longs backups, ajoutez des pings de progression (par exemple toutes les heures) pour détecter les blocages avant le timeout global.
Intégrez une vérification de taille dans votre script. Définissez une taille minimale acceptable basée sur l'historique. Si le fichier est en dessous du seuil, envoyez un ping fail avec "error=file_too_small&size=XXX".
Absolument ! Le cloud n'est pas magique. Les credentials peuvent expirer, les quotas peuvent être atteints, les régions peuvent avoir des incidents. Vérifiez que l'upload a réussi (code retour de aws s3 cp ou gsutil cp) et que le fichier est bien présent et accessible.
Ces outils génèrent souvent des logs ou des hooks. Créez un script cron qui vérifie la présence du dernier backup, sa taille, et envoie le ping en fonction. Vous pouvez aussi utiliser les webhooks de ces outils s'ils en proposent.
Les backups incrémentiels produisent des fichiers de taille variable (parfois très petits si peu de changements). Adaptez vos seuils ou désactivez la vérification de taille pour les incrémentiels. L'important est de vérifier que la chaîne complète (full + incrémentiels) reste cohérente.
Vos backups sont votre dernière ligne de défense contre la perte de données. Ils méritent un niveau de surveillance à la hauteur de leur importance. Un backup non vérifié est aussi dangereux qu'aucun backup - vous pensez être protégé alors que vous ne l'êtes pas.
Avec MoniTao, vous pouvez mettre en place un monitoring complet de vos backups en quelques minutes. Exécution, vérification, alertes - tout est couvert. Ne découvrez plus jamais qu'un backup a échoué au moment où vous en avez besoin.
Commencez gratuitement, sans carte bancaire.