
Sesenta contenedores en un servidor
Un servidor bare-metal ejecuta decenas a cientos de contenedores Hoody. KSM y dedup BTRFS hacen que el costo marginal sea casi cero.
Añade una entrada hoody-cron que dispare cinco minutos antes del job de migración de las 03:00. Hace curl a la URL de snapshots y etiqueta el artefacto como punto de rollback. Si la migración falla, restauras en 30 segundos con un único PATCH.
{ "name": "snap-2026-05-04", "alias": "rollback-point", "created_at": "02:55:08Z" }
UNA NOCHE, CINCO EVENTOS, CERO PÁGINAS
El servicio de cron programa un curl. El servicio de snapshots se encarga de congelar. Ninguno sabe nada del job de migración que corre cinco minutos después, y esa es justo la idea.
# registrar el job de snapshot recurrente (configuración única) curl -X POST \ cron.containers.hoody.com/users/root/entries \ -H "Content-Type: application/json" \ -d '{ "schedule": "55 2 * * *", "command": "curl -X POST $SNAP_URL -d '{\"alias\":\"rollback-point\"}'", "comment": "pre-migration snapshot" }'
# lo que la entrada de cron hace curl cada noche a las 02:55 UTC curl -X POST \ api.hoody.com/api/v1/containers/$ID/snapshots \ -H "Authorization: Bearer $TOKEN" \ -d '{"alias": "rollback-point", "expiry": 7}' # respuesta del servicio de snapshots → 200 OK · snap-2026-05-04 created in 8s
La entrada de cron es una fila en una tabla Postgres en algún sitio dentro de Hoody. La URL de snapshots escribe un blob direccionado por contenido al backend de almacenamiento del contenedor. Ambos son duraderos, ambos están versionados, y ninguno requiere un proceso de larga duración en tu portátil.
Cuatro momentos, cuatro URLs y un hueco de cinco minutos entre la red de seguridad y el cambio. La migración termina antes de que suene el primer despertador de casi nadie.
Si el paso 03 falla, el rollback es `PATCH /snapshots/snap-2026-05-04` y vuelves a 02:55:08Z. La línea de tiempo de auditoría de arriba son los mismos datos, servidos como JSON.
No el snapshot en sí. La forma: un backup que existe antes del cambio, direccionado por una URL, con un nombre que incluye la fecha de hoy.
La mayoría de los post-mortems de incidencias empiezan con "se nos olvidó hacer un backup". Cuando el backup es una entrada de cron, no se puede olvidar. El snapshot de las 02:55 es la primera frase del runbook, escrita por adelantado.
Restaurar snap-2026-05-04 es una sola llamada HTTP contra api.hoody.com. El contenedor vuelve a su estado de 02:55:08Z en menos de 30 segundos. Sin ticket, sin escalado a la guardia, sin "¿quién tiene la consola de AWS?".
Los snapshots están direccionados por contenido y se almacenan como deltas. Un delta de 412 MB sobre un disco base sin cambios es lo que pagas, y solo durante la ventana de retención de 7 días. Las migraciones exitosas casi no dejan huella.
Cómo era el runbook, y en qué se colapsa cuando el snapshot lleva el nombre de la fecha de hoy y es direccionable como una URL.
La nueva columna de la derecha no es una herramienta. Es una sola frase en un runbook. La frase no empieza con "primero, haz un backup" porque el backup ya existe.
El plan de rollback es una URL que programaste para que existiera.
El culto al cargo de los backups previos a migración. Programa el snapshot, duerme con la ventana de migración.
El plan de rollback es una URL que programaste para que existiera.