Un lavoro di backup che smette di funzionare non lo annuncia quasi mai. La posta di cron va in una casella che nessuno legge, lo script esce con un codice di errore nel vuoto, e il guasto si scopre nell'unico giorno in cui serviva. Il rimedio è sorvegliare il successo, non il fallimento.
Scopri cosa è successo
journalctl -u backup.service -n 100 --no-pager
tail -100 /var/log/backup.log
ls -la /srv/backup/ | tail # has anything arrived recently
Le quattro cause abituali
- Spazio finito — la destinazione si è riempita.
df -h. La conservazione non sta potando: vedi Conservazione. - Credenziali scadute — una chiave ruotata o un token S3: la copia viene scritta in locale e non parte mai.
- Un file che non si riesce a leggere — i permessi sono cambiati, e rsync o tar escono con un codice di errore pur avendo fatto quasi tutto.
- Il dump del database è fallito — un blocco scaduto o un permesso mancante, mentre la parte dei file è riuscita e l'esecuzione sembrava a posto.
Fa' che lo script fallisca ad alta voce
#!/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
Senza set -o pipefail, mysqldump | gzip dichiara successo ogni volta che gzip riesce — anche quando mysqldump è morto a metà strada. Quell'unica opzione mancante è il motivo più comune per cui un dump troncato viene archiviato come buono.
Fatti avvisare dal silenzio, non dagli errori
Fa' che il lavoro mandi un battito a un interruttore dell'uomo morto quando riesce. Se il battito smette di arrivare vieni avvisato, e questo copre anche il caso in cui il server sia spento e nessun errore venga mai prodotto.
# last line of the backup script
curl -fsS -m 10 --retry 3 https://hc-ping.com/your-uuid > /dev/null