Configurar backup y monitorizacion de uptime para buzz-relay #10

New Issue

2026-08-12T11:02:29Z

rafa commented

2026-08-12 11:02:29 +00:00

Contexto

buzz-relay (Coolify service buzz-relay, uuid momxc6dl0742b8eulckryjlx) se desplego el
2026-08-08 en Hetzner, fuera del sistema de backups montado el 2026-08-01 (ver wiki Backups
de este repo) y fuera del alcance explicito de Beszel/uptime.

Backup

4 volumenes persistentes sin cubrir:

momxc6dl0742b8eulckryjlx_buzz-postgres-data — mensajes/canales, el dato critico (todo el
estado del relay Nostr)
momxc6dl0742b8eulckryjlx_buzz-minio-data — adjuntos/media (bucket buzz-media)
momxc6dl0742b8eulckryjlx_buzz-redis-data — cache/pubsub, prescindible (regenerable)
momxc6dl0742b8eulckryjlx_buzz-git-data — datos de integracion git de Buzz

Limitaciones a resolver antes de poder automatizarlo con el patron existente (pull por Tailscale
desde la WSL, ver wiki Backups):

Coolify solo hace backup nativo de recursos "Database" propios, nunca de volumenes sueltos.
El postgres de buzz vive dentro de un docker_compose_raw como un servicio mas, no como
recurso Database nativo de Coolify — evaluar si conviene extraerlo o si el dump se hace via
docker exec ... pg_dump ad-hoc (rompe la regla de "todo estandar de Coolify" salvo que se
documente como excepcion deliberada).
minio/redis/git no son bases de datos: necesitan backup a nivel de volumen (docker run --rm -v ...:/data -v backup_dest:/backup ... tar o similar), no el mecanismo de BD de Coolify.

Tareas:

Decidir mecanismo de dump/backup para el postgres de buzz (recurso Database nativo vs
pg_dump programado)
Backup del volumen minio (media) — al menos incluirlo en el pull existente por Tailscale
Evaluar si redis/git necesitan backup real o son recreables sin perdida
Restauracion probada de verdad, como se hizo con feadulta el 2026-08-01

Monitorizacion

Beszel ya cubre CPU/RAM/disco del Hetzner y el estado de los 4 contenedores del servicio (via
docker.sock, se ven con el UUID de Coolify no el nombre legible). Lo que falta:

Uptime check HTTP real de srv1.taild3aaf6.ts.net:8443 (el relay) y :8444 (pair-relay) —
Beszel NO detecta caidas de servicio con contenedor sano (ya paso con
antiguo.feadulta.com el 30-jul). Evaluar Uptime Kuma (propuesto y pendiente desde entonces
para el resto de servicios) o extender el mismo mecanismo aqui.
Alertas de umbral (CPU/RAM/disco) ya configuradas a nivel de servidor deberian cubrir esto
sin trabajo extra — confirmar que los 4 contenedores de buzz aparecen en el hub y no estan
excluidos.
Decidir si aplica alerta especifica de "agente/servicio caido" para buzz o basta con la
generica del servidor.

Relacionado: memoria de sesion buzz-update-redeploy-secretos-202608, issue #9 (piloto Buzz).

## Contexto buzz-relay (Coolify service `buzz-relay`, uuid `momxc6dl0742b8eulckryjlx`) se desplego el 2026-08-08 en Hetzner, fuera del sistema de backups montado el 2026-08-01 (ver wiki `Backups` de este repo) y fuera del alcance explicito de Beszel/uptime. ## Backup 4 volumenes persistentes sin cubrir: - `momxc6dl0742b8eulckryjlx_buzz-postgres-data` — mensajes/canales, el dato critico (todo el estado del relay Nostr) - `momxc6dl0742b8eulckryjlx_buzz-minio-data` — adjuntos/media (bucket `buzz-media`) - `momxc6dl0742b8eulckryjlx_buzz-redis-data` — cache/pubsub, prescindible (regenerable) - `momxc6dl0742b8eulckryjlx_buzz-git-data` — datos de integracion git de Buzz Limitaciones a resolver antes de poder automatizarlo con el patron existente (pull por Tailscale desde la WSL, ver wiki `Backups`): - Coolify solo hace backup nativo de recursos "Database" propios, nunca de volumenes sueltos. - El postgres de buzz vive dentro de un `docker_compose_raw` como un servicio mas, no como recurso Database nativo de Coolify — evaluar si conviene extraerlo o si el dump se hace via `docker exec ... pg_dump` ad-hoc (rompe la regla de "todo estandar de Coolify" salvo que se documente como excepcion deliberada). - minio/redis/git no son bases de datos: necesitan backup a nivel de volumen (`docker run --rm -v ...:/data -v backup_dest:/backup ... tar` o similar), no el mecanismo de BD de Coolify. Tareas: - [ ] Decidir mecanismo de dump/backup para el postgres de buzz (recurso Database nativo vs pg_dump programado) - [ ] Backup del volumen minio (media) — al menos incluirlo en el pull existente por Tailscale - [ ] Evaluar si redis/git necesitan backup real o son recreables sin perdida - [ ] Restauracion probada de verdad, como se hizo con feadulta el 2026-08-01 ## Monitorizacion Beszel ya cubre CPU/RAM/disco del Hetzner y el estado de los 4 contenedores del servicio (via `docker.sock`, se ven con el UUID de Coolify no el nombre legible). Lo que falta: - [ ] Uptime check HTTP real de `srv1.taild3aaf6.ts.net:8443` (el relay) y `:8444` (pair-relay) — Beszel NO detecta caidas de servicio con contenedor sano (ya paso con antiguo.feadulta.com el 30-jul). Evaluar Uptime Kuma (propuesto y pendiente desde entonces para el resto de servicios) o extender el mismo mecanismo aqui. - [ ] Alertas de umbral (CPU/RAM/disco) ya configuradas a nivel de servidor deberian cubrir esto sin trabajo extra — confirmar que los 4 contenedores de buzz aparecen en el hub y no estan excluidos. - [ ] Decidir si aplica alerta especifica de "agente/servicio caido" para buzz o basta con la generica del servidor. Relacionado: memoria de sesion `buzz-update-redeploy-secretos-202608`, issue #9 (piloto Buzz).

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: rafa/server#10