Ein Sicherungsjob, der aufhört zu funktionieren, kündigt das fast nie an. Die Cron-Mail geht in ein Postfach, das niemand liest, das Skript beendet sich mit einem Fehlercode ins Leere, und der Fehlschlag fällt an dem einen Tag auf, an dem man ihn brauchte. Die Lösung ist, den Erfolg zu überwachen, nicht den Fehlschlag.
Finden Sie heraus, was passiert ist
journalctl -u backup.service -n 100 --no-pager
tail -100 /var/log/backup.log
ls -la /srv/backup/ | tail # has anything arrived recently
Die vier üblichen Ursachen
- Kein Platz — das Ziel ist vollgelaufen.
df -h. Die Aufbewahrung räumt nicht auf: siehe Aufbewahrung. - Abgelaufene Zugangsdaten — ein rotierter Schlüssel oder ein S3-Token; die Kopie wird lokal geschrieben und geht nie weg.
- Eine Datei, die sich nicht lesen lässt — die Rechte haben sich geändert, und rsync oder tar beendet sich mit Fehlercode, obwohl das meiste getan ist.
- Der Datenbank-Dump scheiterte — ein Lock-Timeout oder ein fehlendes Recht, während der Dateiteil des Jobs klappte und der Lauf gut aussah.
Lassen Sie das Skript laut scheitern
#!/usr/bin/env bash
set -euo pipefail # stop at the first error, and at an unset variable
trap 'echo "BACKUP FAILED at line $LINENO" | mail -s "backup failed" ops@example.com' ERR
Ohne set -o pipefail meldet mysqldump | gzip Erfolg, sobald gzip erfolgreich ist — auch wenn mysqldump auf halber Strecke gestorben ist. Diese eine fehlende Option ist der häufigste Grund, warum ein abgeschnittener Dump als guter abgelegt wird.
Alarmieren Sie bei Stille, nicht bei Fehlern
Lassen Sie den Job bei Erfolg einen Totmannschalter anpingen. Bleibt der Ping aus, erfahren Sie es — und das deckt auch den Fall ab, dass der Server aus ist und nie ein Fehler entsteht.
# last line of the backup script
curl -fsS -m 10 --retry 3 https://hc-ping.com/your-uuid > /dev/null
Prüfen Sie die GRÖSSE ebenso wie den Exit-Code. Ein Dump, der plötzlich ein Zehntel der Vorwoche misst, ist ein Fehlschlag, der Erfolg gemeldet hat — und genau so sieht jede stille Sicherungskatastrophe aus.