
Sessenta contêineres em um servidor
Uma caixa bare-metal executa dezenas a centenas de contêineres Hoody. KSM e BTRFS dedup fazem o custo marginal próximo a zero.
Uma entrada de cron gerenciada dispara @hourly. Faz POST de um snapshot chamado auto-h$(date +%H). Os nomes ciclam: auto-h00 até auto-h23. Depois de um dia, cada novo snapshot sobrescreve o de ontem na mesma hora — e você sempre tem as últimas 24 horas de estado, retidas com granularidade horária.
{ "name": "hourly-2026-05-04-13", "alias": "auto-h13", "created_at": "13:00:04Z", "size": 1331691520 }
o elevador para em 24 andares — a hora de ontem é sobrescrita pela de hoje
Uma entrada gerenciada @hourly faz curl na URL de snapshots com o alias auto-h$(date +%H). O alias colide de propósito: amanhã às 13h, o auto-h13 de hoje é substituído. Vinte e quatro slots nomeados, rotacionados automaticamente.
# Hoody Cron — agenda um snapshot horário. 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" }'
# Às 13:00 o cron roda — esta é a requisição que ele envia: curl -X POST \ api.hoody.com/api/v1/containers/$ID/snapshots \ -H "Authorization: Bearer $TOKEN" \ -d '{"alias": "auto-h13"}' # Resposta: → 200 OK · hourly-2026-05-04-13 created in 6s
Não há política de retenção e não há janitor — o alias auto-h13 é reusado a cada 24 horas, e é isso que faz a janela rolar. A Hoody Snapshots API suporta um campo alias opcional em POST /api/v1/containers/[id]/snapshots; reusá-lo é o mecanismo inteiro.
Quatro passos, todos dentro de um único curl. Do tick do cron ao snapshot em segundos.
Cada tick leva segundos. O alias é a primitiva de rotação — ao reusar o mesmo nome 24 horas depois, o snapshot naquele andar é substituído no lugar.
O que você abre mão ao deletar o runbook de backup, você ganha de volta como algo mais barato e mais honesto.
Snapshots são stateless em disco; não queimam CPU ou RAM enquanto estão lá. Você está pagando armazenamento por 24 cópias do diff do contêiner, não por um serviço de backup que roda o tempo todo.
Quando algo dá errado às 14:14, você restaura o auto-h13 e está de volta às 13:00 — um minuto antes do problema começar. Horária é fina o suficiente para rollback de produção e grossa o suficiente para não afogar o ledger.
Não há política de ciclo de vida para escrever, sem bucket S3 para provisionar, sem revisão anual de runbook. A convenção de nomes é a regra de retenção. O conjunto fixo de aliases é a auditoria.
Vinte e quatro snapshots de um contêiner típico, retidos com granularidade horária. Os números vêm da Hoody Snapshots API e de um diff representativo de 1,2 GB por hora.
Cada hora é um slot nomeado. Depois do primeiro dia, todo novo snapshot sobrescreve o de ontem na mesma hora — a contagem nunca cresce.
Uma entrada gerenciada, schedule @hourly, command faz curl na URL de snapshots com alias auto-h$(date +%H). É a rotação inteira.
Sem job de prune, sem política de expires_at, sem config de ciclo de vida. A colisão de alias rotaciona a janela no lugar; nada acumula.
Conforme a Hoody Container Snapshots API: POST /api/v1/containers/[id]/snapshots aceita um alias opcional (máx. 100 chars) e uma expiração opcional em dias. Esta página assume o preço padrão de snapshots dos contêineres e um diff representativo de ~1,2 GB por captura horária; seus tamanhos vão variar conforme a workload.
Sua máquina do tempo tem 24 andares e o elevador é um curl.
As ferramentas padrão para quando você quer recuperação point-in-time horária. Cada uma te cobra um serviço ou uma política de retenção. O modelo cron + alias não cobra nenhum dos dois.
Delete o runbook de backup. Agende o @hourly. As últimas 24 horas do seu contêiner existem como 24 andares nomeados — e o elevador é um único curl.