Alertas de fallo de backup: entérate antes de restaurar

Los backups fallan en silencio durante semanas. Detecta errores de restic y borg, snapshots obsoletos y ejecuciones perdidas, y recibe una llamada.

Actualizado

Índice

La mayoría descubre que sus backups estaban rotos el día que los necesita. El trabajo terminó con un error hace tres semanas, nadie leyó el log y el snapshot más reciente es anterior al error que intentas deshacer.

La solución no es una herramienta de backup mejor. Es asegurarte de que un problema de backup llegue a una persona en la misma hora en que ocurre. Esta guía muestra cómo hacerlo con restic y borg (y con cualquier cosa que se ejecute desde una shell), cubriendo las tres formas en que los backups fallan de verdad, con scripts que puedes copiar. El último paso envía la alerta a tu teléfono a través de Echobell, de modo que un backup roto suena en lugar de quedarse en una bandeja de correo.

Las tres formas en que falla un backup

Vigilar solo la primera es el error más común.

  1. Se ejecuta y falla. Repositorio bloqueado, disco lleno, contraseña incorrecta, caída de red. La herramienta termina con un código distinto de cero.
  2. Se ejecuta y tiene éxito a medias. restic termina con el código 3 cuando se creó un snapshot pero algunos archivos no se pudieron leer. borg termina con 1 en caso de advertencias. Ambos son fáciles de ignorar y ambos pueden esconder un problema de permisos que omite en silencio tu directorio más importante.
  3. Nunca se ejecuta. El servidor estaba apagado, el timer desactivado, el crontab sobrescrito. No hay error porque no hay proceso. Este es el fallo que más daño hace.

Cada uno necesita un detector distinto, así que construiremos los tres.

Paso 1 — Crea un canal que pueda captar tu atención

En Echobell, crea un canal llamado backups y pon su tipo de notificación en Llamada para los trabajos que importan. Copia su URL de webhook:

https://hook.echobell.one/t/<channel-token>

Dale plantillas que se entiendan medio dormido, usando los campos que enviaremos más abajo:

Título: Backup {{status}} en {{host}}
Cuerpo: {{job}}: {{detail}}

Consulta la referencia de plantillas para ver la sintaxis.

Paso 2 — Detecta los fallos con un script envoltorio

Un pequeño script envoltorio convierte los códigos de salida en alertas. Guárdalo como /usr/local/bin/backup-run:

#!/usr/bin/env bash
set -uo pipefail

HOOK="https://hook.echobell.one/t/<channel-token>"
JOB="nightly-restic"

alert() {
  curl -fsS -m 10 -X POST "$HOOK" \
    -H "Content-Type: application/json" \
    -d "{\"job\":\"$JOB\",\"host\":\"$(hostname)\",\"status\":\"$1\",\"detail\":\"$2\"}" || true
}

restic backup /srv /etc --exclude-caches
code=$?

case $code in
  0)  ;;                                   # éxito: guardar silencio
  3)  alert "incomplete" "Snapshot saved, but some files were unreadable" ;;
  11) alert "locked" "Repository is locked by another process" ;;
  12) alert "auth-failed" "Wrong repository password" ;;
  *)  alert "failed" "restic exited with code $code" ;;
esac

exit $code

Por qué importan los detalles:

  • set -e no se usa a propósito, para que el script llegue a la alerta aunque restic falle.
  • || true en el curl hace que un webhook inalcanzable nunca oculte el código de salida real.
  • -m 10 evita que una llamada de red colgada bloquee la siguiente ejecución programada.

Los códigos de salida de restic usados arriba están documentados en el manual de restic: 0 éxito, 1 error fatal, 3 snapshot creado pero algunos archivos de origen ilegibles, 10 el repositorio no existe, 11 no se pudo bloquear, 12 contraseña incorrecta. Compruébalos con restic version en tu propia máquina, porque se han ido añadiendo códigos con el tiempo.

borg y borgmatic

borg devuelve 0 si todo va bien, 1 para advertencias y 2 o más para errores. Que un archivo cambie durante el backup produce 1, algo rutinario en directorios de logs, así que un enfoque habitual es avisar con llamada solo a partir de 2 y enviar una notificación discreta para 1:

borg create --stats ::'{hostname}-{now}' /srv /etc
code=$?
if [ "$code" -ge 2 ]; then
  alert "failed" "borg exited with code $code"
elif [ "$code" -eq 1 ]; then
  alert "warning" "borg finished with warnings"
fi

Si usas borgmatic, su hook on_error ejecuta un comando cuando el propio borgmatic encuentra un error, que es el lugar natural para el mismo curl. Ten en cuenta el límite que reconoce la propia documentación de borgmatic: si borgmatic nunca se ejecuta, on_error nunca se dispara. Ese es el fallo número tres, y necesita el Paso 3.

Paso 3 — Detecta el backup que nunca se ejecutó

Un script envoltorio solo puede informar de una ejecución que ocurrió. Para detectar el silencio, invierte la lógica: el backup envía un ping a un monitor cuando tiene éxito, y el monitor te avisa cuando el ping llega tarde. Esto se llama dead man's switch (interruptor de hombre muerto).

Healthchecks.io (alojado o autoalojado) hace exactamente esto:

  1. Crea un check con la programación 0 3 * * * y un tiempo de gracia de una o dos horas.
  2. Añade su ping al final de tu trabajo para que solo se dispare si hay éxito.
  3. En las integraciones del check, añade un Webhook que apunte a la URL de tu canal de Echobell.

El ping va al final del script envoltorio:

# en backup-run, justo antes del `exit $code` final; solo hace ping si hubo éxito
if [ $code -eq 0 ]; then
  curl -fsS -m 10 --retry 3 -o /dev/null https://hc-ping.com/<your-uuid>
fi

Healthchecks también admite las variantes de ping /start y /fail y puede recibir el código de salida en la URL, así que un solo check puede detectar también trabajos que se cuelgan. El resultado: un servidor caído, un timer desactivado y una línea de crontab borrada producen el mismo desenlace, un teléfono que suena. Para el patrón general y otros monitores, consulta alertas de fallo de cron jobs.

Paso 4 — Comprueba que el backup está al día y es restaurable

Un backup puede ejecutarse a su hora, terminar con 0 y aun así ser inútil, por ejemplo cuando estás respaldando un directorio vacío porque falló un montaje. Añade dos comprobaciones baratas en un trabajo diario aparte:

Antigüedad del snapshot. Alerta si el snapshot más reciente es más viejo de lo esperado:

latest=$(restic snapshots --latest 1 --json | jq -r '.[0].time')
age_h=$(( ( $(date +%s) - $(date -d "$latest" +%s) ) / 3600 ))
if [ "$age_h" -gt 30 ]; then
  alert "stale" "Newest snapshot is ${age_h}h old"
fi

Integridad del repositorio. restic check verifica la estructura del repositorio. Ejecútalo semanalmente; en repositorios grandes, restic check --read-data-subset=5% toma una muestra de los datos sin leerlo todo. Alerta si el código de salida no es cero.

Ninguna sustituye a una restauración de prueba real. Una vez por trimestre, restaura a un directorio temporal un archivo que puedas verificar. Es la única prueba que demuestra que el backup funciona.

Paso 5 — Que suene solo cuando importa

Si cada advertencia te llama, acabarás silenciando el canal, y entonces no sonará para la que de verdad cuenta. Usa las condiciones de Echobell para separar niveles en un mismo canal:

status == "failed" || status == "stale" || status == "auth-failed"

Envía incomplete y warning a un segundo canal Urgente (Time Sensitive) o normal, para que aparezcan en la pantalla de bloqueo sin sonar. Añade una ventana horaria si quieres que los fallos diurnos sean discretos, usando las variables UTC descritas en la referencia de condiciones.

Preguntas frecuentes

¿Cómo recibo un aviso cuando falla un backup?

Envuelve el comando de backup, lee su código de salida y envía un webhook ante cualquier código distinto de cero. Añade un dead man's switch como Healthchecks.io para enterarte también de las ejecuciones que nunca empezaron.

¿Ante qué códigos de salida de restic debo alertar?

Alerta con fuerza ante 1, 10, 11 y 12, que indican un fallo real. Trata 3 (snapshot creado pero algunos archivos ilegibles) como una advertencia que investigar, ya que puede esconder un problema de permisos.

¿Cómo sé si un backup dejó de ejecutarse en silencio?

Usa un heartbeat: el trabajo envía un ping a un monitor cuando tiene éxito, y el monitor avisa cuando el ping llega tarde. Un hook de error no puede detectarlo porque no se ejecuta nada que lance el error.

¿Basta un código de salida correcto para fiarse de un backup?

No. Significa que la herramienta terminó, no que los datos estén completos o sean restaurables. Comprueba la antigüedad de los snapshots, ejecuta comprobaciones de integridad periódicas y prueba una restauración con regularidad.

¿Puedo recibir una llamada en lugar de un correo?

Sí. El correo es fácil de pasar por alto. Un canal de llamada en Echobell se comporta como una llamada entrante y atraviesa el modo Concentración de iOS, así que un backup fallido a las 03:00 se nota.

Cierre

Tres detectores cubren los tres modos de fallo: un script envoltorio con códigos de salida para las ejecuciones que fallan, una comprobación de frescura para las que tienen éxito sin servir de nada, y un heartbeat para las que nunca ocurren. Enrútalos a un canal de llamada, deja las advertencias en uno más discreto, y un backup roto se convierte en un arreglo de cinco minutos en lugar de un fin de semana perdido.

Descarga Echobell para iPhone o consíguelo en Google Play, crea el canal backups y ejecuta el script una vez con una contraseña deliberadamente incorrecta para oírlo sonar.

Artículos relacionados

Artículos relacionados

Alertas de CloudWatch por llamada sin Lambda ni Twilio

SNS no puede llamar a un teléfono. Enruta las alarmas de CloudWatch por EventBridge a un webhook de llamada: configuración, filtros y trampas.

Leer más

Alertas de Sentry por llamada para errores críticos

Sentry no tiene acción de llamada. Enruta sus alertas por webhook para que solo los errores que rompen producción hagan sonar tu teléfono.

Leer más

Alertas de cron jobs: recibe una llamada cuando un job muere

Los cron jobs fallan en silencio. Tres patrones fiables para detectar jobs fallidos u omitidos y recibir una notificación push o una llamada en segundos.

Leer más