Leer el registro de una copia fallida

Una tarea de copia que deja de funcionar casi nunca lo anuncia. El correo de cron va a un buzón que nadie lee, el script sale con código de error hacia el vacío, y el fallo se descubre el único día en que hacía falta. El arreglo es vigilar el éxito, no el fallo.

Averigua qué pasó

journalctl -u backup.service -n 100 --no-pager
tail -100 /var/log/backup.log
ls -la /srv/backup/ | tail          # has anything arrived recently

Las cuatro causas habituales

• Sin espacio: el destino se llenó. df -h. La conservación no está podando: consulta Conservación.
• Credenciales caducadas: una clave rotada o un token de S3, de modo que la copia se escribe en local y nunca sale.
• Un archivo que no se puede leer: cambiaron los permisos, y rsync o tar salen con código de error con casi todo el trabajo hecho.
• El volcado de la base falló: un bloqueo caducado o un permiso ausente, mientras la parte de archivos salió bien y la ejecución parecía correcta.

Haz que el script falle a gritos

#!/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

Sin set -o pipefail, mysqldump | gzip informa de éxito siempre que gzip lo tenga, aunque mysqldump haya muerto a medio camino. Esa única opción ausente es la razón más común de que un volcado truncado se guarde como bueno.

Avisa por el silencio, no por los errores

Haz que la tarea mande una señal a un interruptor de hombre muerto cuando tenga éxito. Si la señal deja de llegar, te enteras, y eso cubre también el caso en que el servidor está apagado y no se produce ningún error.

# last line of the backup script
curl -fsS -m 10 --retry 3 https://hc-ping.com/your-uuid > /dev/null