Usa Uptime Kuma y hooks de vzdump para monitorizar tus backups de Proxmox
Un administrador comparte su implementación para evitar falsos positivos en las alertas de respaldo de máquinas virtuales y contenedores.
Los correos de estado de backup diarios suelen convertirse en ruido que termina ignorándose. Cuando falta uno, nadie lo nota hasta que hay que restaurar algo y no está. sbarmen ha publicado en el subreddit de autoalojamiento una implementación para usar Uptime Kuma como sistema de alertas para un cluster de Proxmox Virtual Environment (PVE). La solución evita las credenciales de la API y detecta tanto fallos individuales como la ausencia total de trabajos programados.
La lógica del hook
La clave está en explotar los hooks de vzdump en lugar de llamar directamente a la API de Proxmox. Al configurar el script en /etc/vzdump.conf, se elimina la necesidad de gestionar tokens o usuarios con permisos de lectura. El mecanismo funciona asignando un monitor de tipo push por cada nodo del clúster. Cuando comienza un backup, se envía un estado "up". Si finaliza sin errores, otro "up". Cualquier fallo envía "down". Además, el intervalo de latido de 86.400 segundos marca el monitor como caído si el nodo deja de enviar señales, captando así fallos de planificación o servicios detenidos.
El autor señala un detalle crítico en la documentación de vzdump: el hook job-end se ejecuta incluso si una máquina virtual o contenedor dentro del job falla. Un script que solo verificara el final del trabajo reportaría éxito parcial oculto. Para evitarlo, el script registra los fallos en la fase backup-abort y analiza los registros individuales en log-end. Toda esta información se almacena en un archivo de estado en /run y se evalúa una sola vez en job-end.
Hay un problema adicional con las variables de entorno. vzdump ejecuta el hook con un entorno limpio, por lo que la variable PATH vacía impide que se ejecuten binarios básicos si no se definen explícitamente al inicio del script. Asimismo, LOGFILE solo tiene valor durante la fase log-end; si el almacenamiento es Proxmox Backup Server (PBS), esa variable es nula. El diseño usa backup-abort como respaldo para ese caso específico.
Operatividad y seguridad
Un punto operativo importante es el código de salida. Si el script devuelve un error (código distinto de cero), vzdump marca todo el trabajo de backup como fallido. Esto puede ser contraproducente si el fallo es solo del sistema de monitorización. Por eso, el script siempre termina con exit 0, asegurando que la monitorización nunca interrumpa el proceso de respaldo.
Para probar la configuración sin esperar a la ventana de backup, se pueden invocar las fases manualmente en orden:
/usr/local/bin/backup-hook.sh job-start
/usr/local/bin/backup-hook.sh backup-abort snapshot 101
/usr/local/bin/backup-hook.sh job-end
El sistema de alertas puede ir hacia cualquier canal soportado por Uptime Kuma: Signal, Discord, WhatsApp o correo electrónico. El autor prefiere Signal para la acción inmediata y el correo para el registro histórico. La implementación completa, incluyendo el código del script y la configuración de los monitores, está disponible en su sitio web personal. Valga la pena mencionar que este enfoque es específico para entornos donde se desea baja fricción operativa y cero mantenimiento de credenciales API.