← Volver al blog devops

Fiestas Patrias y el servidor que se queda solo: probando qué tan resiliente es de verdad

17 de septiembre de 2026 · Rodolfo Ulloa
Fiestas Patrias y el servidor que se queda solo: probando qué tan resiliente es de verdad
devopsinfraestructuradockerbackupsinteligencia-artificial

El 18 de septiembre en Chile significa asado, fin de semana largo y, en mi caso, cuatro días sin tocar una terminal si todo sale bien. Pero un servidor casero no entiende de Fiestas Patrias: los timers de systemd siguen corriendo, las actualizaciones automáticas de seguridad siguen aplicándose, y si algo se cae un martes de asado nadie lo va a notar hasta el jueves. Esta semana me puse a revisar, servicio por servicio, qué tan preparada está mi infraestructura para que yo esté ausente de verdad — no "revisando el celular cada rato", sino ausente.

La pregunta no es "¿funciona?", es "¿se recupera sola?"

Todos mis contenedores corren con restart: unless-stopped en el docker-compose.yml, así que en teoría un contenedor que muere por su cuenta (memoria, una excepción no capturada, lo que sea) vuelve a levantarse solo. En teoría. Lo que nunca había probado en serio era el caso más común en la práctica: que el que se caiga no sea el contenedor, sino el propio cloudflared que sostiene el túnel. Sin él, da lo mismo que todos los servicios estén sanos puertas adentro — hacia afuera, ulloa.cc completo desaparece.

Hice la prueba tonta pero necesaria: maté el proceso de cloudflared a mano y crono­metré cuánto tardaba en reconectar. Volvió solo en segundos, con backoff exponencial incorporado, sin que tuviera que intervenir. Pero el punto no es que funcionara — es que antes de esta semana yo asumía que funcionaba y nunca lo había verificado con el servidor en un estado real de falla, no solo leyendo la documentación de Cloudflare.

Espacio en disco: el fallo silencioso que no manda alerta

El caso que más me preocupaba no era una caída dramática, sino algo aburrido: que el disco se llenara de logs de Docker o de imágenes viejas sin usar mientras yo no estaba mirando. Un contenedor que no puede escribir porque el disco está lleno no siempre falla de forma ruidosa — a veces simplemente deja de responder, y ahí sí que ningún restart: unless-stopped te salva, porque el contenedor técnicamente sigue "arriba".

Antes de este fin de semana largo dejé corriendo docker system prune con criterio (revisando antes qué iba a borrar, no a ciegas) y until until until, además revisé que mi mini-dashboard de monitoreo tuviera un umbral de disco visible de un vistazo desde el celular. No es una alerta push todavía — es la próxima mejora obvia — pero al menos puedo chequearlo en diez segundos desde la mesa del asado sin tener que abrir una terminal SSH delante de la familia.

Backups: la pregunta que ya me había hecho antes

Esta no es nueva para mí — ya escribí sobre el día que tuve que restaurar un backup de verdad — pero un fin de semana largo es exactamente el tipo de ventana donde algo puede salir mal y no enterarme hasta que sea demasiado tarde para actuar rápido. Confirmé que los snapshots de restic seguían corriendo en su horario, y no solo eso: verifiqué que el job de backup en sí no dependiera de que yo estuviera despierto para reintentarlo si fallaba una vez. Un backup que solo corre una vez al día y no reintenta en caso de error es, en la práctica, un backup que puede fallar en silencio justo la semana que más lo necesitas.

Lo que sí voy a revisar desde el celular

No voy a fingir que me voy a desconectar del todo — eso sería mentirle al lector. Si algo se ve raro en el dashboard, mi plan es el mismo que ya tengo armado para el día a día: tirar los logs relevantes a claude -p desde el teléfono para un diagnóstico rápido antes de decidir si vale la pena abrir el laptop, algo que ya vengo usando para triage cotidiano. La diferencia esta semana es que la barra para intervenir es más alta a propósito: si el sistema se recupera solo, dejo que se recupere solo, aunque me llegue la notificación.

La lección real

Preparar un servidor para que sobreviva sin supervisión no es una tarea distinta a operarlo bien el resto del año — es la misma disciplina de DevOps de siempre (restart policies, límites de recursos, backups verificados, observabilidad mínima) puesta a prueba con una fecha límite real en el calendario. La diferencia es que normalmente uno posterga esa verificación indefinidamente, y un fin de semana largo con feriado irrenunciable es, sin quererlo, el mejor forzador de disciplina operativa que he tenido este año.