
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.
Una entrada de cron gestionada se dispara @hourly. Hace POST de una snapshot llamada auto-h$(date +%H). Los nombres ciclan: auto-h00 a auto-h23. Tras un día, cada nueva snapshot sobrescribe la de ayer a la misma hora — y siempre tienes las últimas 24 horas de estado, retenidas con granularidad horaria.
{ "name": "hourly-2026-05-04-13", "alias": "auto-h13", "created_at": "13:00:04Z", "size": 1331691520 }
el ascensor para en 24 plantas — la hora de ayer es sobrescrita por la de hoy
Una entrada gestionada @hourly hace curl a la URL de snapshots con alias auto-h$(date +%H). El alias colisiona a propósito: a las 13 de mañana, auto-h13 de hoy es reemplazada. Veinticuatro slots con nombre, rotados automáticamente.
# Hoody Cron — programa una snapshot horaria. curl -X POST \ cron.containers.hoody.com/users/root/entries \ -H "Content-Type: application/json" \ -d '{ "schedule": "@hourly", "command": "curl -X POST $SNAP_URL -d '{\"alias\":\"auto-h$(date +%H)\"}'", "comment": "rolling 24h snapshot" }'
# A las 13:00 corre el cron — esta es la petición que envía: curl -X POST \ api.hoody.com/api/v1/containers/$ID/snapshots \ -H "Authorization: Bearer $TOKEN" \ -d '{"alias": "auto-h13"}' # Respuesta: → 200 OK · hourly-2026-05-04-13 created in 6s
No hay política de retención ni conserje — el alias auto-h13 se reutiliza cada 24 horas, que es lo que hace rodar la ventana. La API de Hoody Snapshots soporta un campo alias opcional en POST /api/v1/containers/[id]/snapshots; reutilizarlo es todo el mecanismo.
Cuatro pasos, todos dentro de un único curl. Del tick del cron a la snapshot en segundos.
Cada tick tarda segundos. El alias es la primitiva de rotación — al reutilizar el mismo nombre 24 horas después, la snapshot de esa planta se reemplaza en el sitio.
Lo que renuncias borrando el runbook de backup, lo recuperas como algo más barato y más honesto.
Las snapshots no consumen estado en disco; no queman CPU ni RAM mientras están ahí. Pagas por el almacenamiento de 24 copias del diff del contenedor, no por un servicio de backup que corre todo el tiempo.
Cuando algo va mal a las 14:14, restauras auto-h13 y vuelves a las 13:00 — un minuto antes de que empezara el problema. Una hora es lo bastante fina para un rollback de producción y lo bastante gruesa para no ahogar el libro mayor.
No hay política de ciclo de vida que escribir, ni bucket S3 que aprovisionar, ni revisión anual de runbook. La convención de nombres es la regla de retención. El conjunto fijo de alias es la auditoría.
Veinticuatro snapshots de un contenedor típico, retenidas con granularidad horaria. Los números salen de la API de Hoody Snapshots y de un diff representativo de 1,2 GB por hora.
Cada hora es un slot con nombre. Después del primer día, cada nueva snapshot sobrescribe la de ayer a la misma hora — el contador nunca crece.
Una entrada gestionada, schedule @hourly, comando hace curl a la URL de snapshots con alias auto-h$(date +%H). Esa es toda la rotación.
Sin trabajo de poda, sin política expires_at, sin configuración de ciclo de vida. La colisión de alias rota la ventana en el sitio; nada se acumula.
Según la API de Hoody Container Snapshots: POST /api/v1/containers/[id]/snapshots acepta un alias opcional (máx. 100 caracteres) y una expiración opcional en días. Esta página asume el precio por defecto de snapshots de contenedores y un diff representativo de ~1,2 GB por captura horaria; tus tamaños variarán según la carga de trabajo.
Tu máquina del tiempo tiene 24 plantas y el ascensor es un curl.
Las herramientas estándar a las que recurres cuando quieres recuperación punto-en-tiempo horaria. Cada una te cobra un servicio o una política de retención. El modelo cron + alias no te cobra ninguna.
Borra el runbook de backup. Programa el @hourly. Las últimas 24 horas de tu contenedor existen como 24 plantas con nombre — y el ascensor es un único curl.