Heartbeats: cómo saber que tus backups realmente corren
El problema del backup silencioso
Configuras un cronjob que hace backup cada noche. Perfecto. Pero, ¿cómo sabes que realmente corre? ¿Que no falló la semana pasada y nadie lo notó?
La mayoría de la gente lo descubre cuando intenta restaurar y no hay nada que restaurar. Es el peor momento posible para enterarse: cuando más lo necesitas y cuando ya no puedes hacer nada al respecto.
Este escenario es más común de lo que parece. No porque la gente no haga backups — la mayoría los configura. El problema es que un backup es un script que corre en silencio, sin interfaz, sin confirmación visible. Si falla, no hay nadie que lo vea fallar. El cronjob aparece como activo en crontab -l, el disco tiene espacio, no hay ninguna señal de alarma. Simplemente no se ejecutó, o se ejecutó pero falló antes de llegar a copiar nada.
Por qué fallan los cronjobs que "funcionan"
Hay un conjunto de fallos clásicos que afectan a cronjobs que llevan meses funcionando sin problemas:
El entorno de cron no es tu entorno de usuario. Cuando ejecutas un script manualmente, tienes tu PATH, tus variables de entorno, tus aliases. Cron arranca con un entorno mínimo. Si tu script llama a rclone o restic y esos binarios están en /home/usuario/bin pero no en /usr/local/bin, el cronjob los encontrará cuando lo pruebas manualmente y fallará en silencio cuando cron lo ejecute.
Las rutas relativas. Un script que funciona desde /home/usuario puede fallar cuando cron lo ejecuta desde / porque las rutas relativas ya no apuntan a donde deben.
El disco lleno o el destino no disponible. Si tu NAS está apagado, si el montaje NFS se cayó o si el bucket S3 tiene problemas de acceso, el script puede terminar sin error pero sin haber copiado nada.
El timeout silencioso. Un backup que normalmente tarda 20 minutos puede tardar 3 horas si hay un problema de red, y si no tienes ningún mecanismo de control, nunca lo sabrás.
Qué es un heartbeat
Un heartbeat es una señal que tu script envía a SecuryBlack para confirmar que se ejecutó correctamente hasta el final. Si la señal no llega en el tiempo configurado, recibes una alerta.
La lógica es invertida respecto al uptime monitoring tradicional. En el uptime monitoring, tú compruebas si algo está vivo haciendo peticiones periódicas. Con heartbeats, es tu script el que avisa cuando termina. Si no avisa, algo ha ido mal.
Esta inversión es importante: un heartbeat detecta tanto que el script no se ejecutó como que se ejecutó pero falló antes de llegar al final. Si pones el curl al final del script, solo llegará si todo lo anterior funcionó correctamente.
Cómo configurarlo
Añade una línea al final de tu script de backup:
curl -fsS https://securyblack.com/api/heartbeat/TU_ID > /dev/null
El flag -f hace que curl falle silenciosamente si el servidor devuelve un error HTTP. El flag -s suprime la salida normal. El flag -S muestra errores si los hay. Redirigir a /dev/null evita que la salida contamine los logs de cron.
Eso es todo. Si el script corre y llega al final, la señal llega. Si no corre o falla antes — por cualquier motivo — no llega, y SecuryBlack te avisa.
Configurar el periodo de gracia
En SecuryBlack puedes configurar cuánto tiempo puede pasar sin recibir el heartbeat antes de considerarlo fallido. Esto se llama el periodo de gracia.
Si tu backup corre a las 2:00 AM y normalmente tarda entre 15 y 45 minutos dependiendo de cuántos datos hayan cambiado, un periodo de gracia de 90 minutos es razonable: si a las 3:30 AM no ha llegado el ping, algo está mal.
El periodo de gracia evita falsas alarmas por variaciones normales en el tiempo de ejecución sin dejar pasar problemas reales demasiado tiempo.
Script con manejo de errores
Un patrón más robusto es usar set -e al principio del script para que cualquier error lo detenga inmediatamente, y así el heartbeat solo se envía si todo salió bien:
#!/bin/bash
set -euo pipefail
# Tu lógica de backup aquí
rclone sync /data remote:backup/
# Solo llega aquí si todo lo anterior funcionó
curl -fsS https://securyblack.com/api/heartbeat/TU_ID > /dev/null
Con set -euo pipefail, si cualquier comando del script falla, el script se detiene y el curl no se ejecuta, lo que activa la alerta.
Casos de uso típicos
Los heartbeats no son solo para backups. Cualquier tarea programada que necesites verificar que corre es un caso de uso válido:
- Backups nocturnos con rsync, rclone, restic o borgbackup
- Scripts de sincronización entre servidores o hacia cloud storage
- Tareas de mantenimiento — rotación de logs, limpieza de temporales, actualización de bases de datos locales
- Scripts de notificación — si tienes un script que te manda un resumen diario y un día no llega, quieres saber por qué
- Cualquier cronjob crítico cuyo fallo silencioso tenga consecuencias
La regla es simple: si un script puede fallar y nadie se enteraría hasta que sea demasiado tarde, merece un heartbeat.
¿Quieres configurar heartbeats para tus scripts y backups? SecuryBlack Heartbeats está disponible gratis durante la beta — añades una línea de curl y listo.