一台服务器上运行 60 个容器
一个裸金属服务器运行数十到数百个 Hoody 容器。KSM 和 BTRFS 去重使边际成本接近零。
容器·快照
use-cases / rolling-24h-snapshots / hero
CRON · SNAPSHOTS · ROLLING 24
把过去 24 小时保留为 24 个快照
一条受管理的 cron 条目每小时触发。它 POST 一个以 auto-h$(date +%H) 命名的快照。名字循环:auto-h00 到 auto-h23。一天后,每个新快照覆盖昨天同一小时的那个 —— 你永远拥有过去 24 小时的状态,以小时粒度保留。
containers.hoody.com · snapshots
https://containers.hoody.com/snapshots/rolling-24hlive · 24/24
楼层 · 最近 24 小时24 / 24
所选快照auto-h13
快照 id1.24 GB
hourly-2026-05-04-13// GET /snapshots — 完整记录:
{ "name": "hourly-2026-05-04-13", "alias": "auto-h13", "created_at": "13:00:04Z", "size": 1331691520 }
PATCH · 1 curl
滚动窗口 · 24 个小时快照16:00 · 12 分钟后过期
−24h−12hnow
电梯停 24 层 —— 昨天的某个小时被今天的同一小时覆盖
use-cases / rolling-24h-snapshots / mechanism
一条 cron,一个命名约定
一条 @hourly 受管理条目用 auto-h$(date +%H) 作为别名 curl 快照 URL。别名是有意冲突的:明天 13 点时,今天的 auto-h13 被替换。24 个命名槽位,自动轮换。
cron 条目 · @hourly
POST · cron/entries# Hoody Cron — 安排一个每小时的快照。 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" }'
小时名就是轮换键
快照 URL · cron 实际命中的地方
POST · containers/[id]/snapshots# 13:00 cron 运行 —— 它发送的就是这个请求: curl -X POST \ api.hoody.com/api/v1/containers/$ID/snapshots \ -H "Authorization: Bearer $TOKEN" \ -d '{"alias": "auto-h13"}' # 响应: → 200 OK · hourly-2026-05-04-13 created in 6s
没有保留策略,也没有清道夫 —— 别名 auto-h13 每 24 小时被复用一次,正是这一点让窗口滚动起来。Hoody Snapshots API 在 POST /api/v1/containers/[id]/snapshots 上支持一个可选的 alias 字段;复用它就是整个机制。
use-cases / rolling-24h-snapshots / anatomy
一个滚动小时的解剖
四步,全都在一次 curl 之内。从 cron 触发到快照,只要数秒。
0113:00:00Cron 触发@hourly · 受管理条目
0213:00:04快照已 POST别名 auto-h13
0313:00:06楼层落地hourly-2026-05-04-13
04+24h同一别名覆盖它无需清道夫
每次触发只要数秒。别名是轮换的原语 —— 24 小时后复用同样的名字,该楼层的快照就会被原地替换。
use-cases / rolling-24h-snapshots / powers
24 层时光机的三种力量
你删掉备份手册放弃的东西,会以更便宜更诚实的方式拿回来。
ECONOMICS
闲置快照几乎不花钱
快照在磁盘上是无状态的;它们在那里时不烧 CPU 也不占内存。你为容器差量的 24 份副本支付存储,而不是为一个全天运行的备份服务付费。
GRANULARITY
一小时是后悔的单位
14:14 出问题时,你恢复 auto-h13,就回到了 13:00 —— 问题开始前一分钟。小时粒度对生产回滚来说足够细,对账本来说又足够粗,不会被淹没。
OPERATIONS
无保留规则,无审计
没有生命周期策略要写,没有 S3 桶要开,没有年度手册评审。命名约定就是保留规则。固定的别名集合就是审计。
use-cases / rolling-24h-snapshots / economics
滚动窗口的成本
一个典型容器的 24 个快照,以小时粒度保留。数字来自 Hoody Snapshots API 和每小时约 1.2 GB 的代表性差量。
- FLOORS RETAINED24
每小时是一个命名槽位。第一天之后,每个新快照都覆盖昨天同一小时的那个 —— 数量永不增长。
- OF CRONTAB1 line
一条受管理条目,@hourly 调度,命令用别名 auto-h$(date +%H) curl 快照 URL。整个轮换就是这样。
- JANITORS0
无清理任务、无 expires_at 策略、无生命周期配置。别名冲突原地轮换窗口;什么都不会累积。
依据 Hoody Container Snapshots API:POST /api/v1/containers/[id]/snapshots 接受可选的 alias(最多 100 字符)和可选的过期天数。本页假设容器的默认快照定价和每次小时捕获约 1.2 GB 的代表性差量;实际大小会随负载而变。
use-cases / rolling-24h-snapshots / punchline
你的时光机有 24 层,电梯是一条 curl。
之前 · 备份软件之后 · 一行 cron
WHAT IT USED TO LOOK LIKERDS snapshots + lifecycle policy + S3 bucket + annual audit四个活动部件 · 按 GB-天计费 · 手册一页
WHAT IT LOOKS LIKE NOW@hourly curl POST snapshots -d '["alias":"auto-h$(date +%H)"]'一行 cron · 一个命名约定 · 24 层楼
use-cases / rolling-24h-snapshots / replaces
这取代了什么
想要按小时进行时间点恢复时常会去够的工具。每一个都向你收一份服务费或一份保留策略费。cron + 别名模型两个都不收。
- AWS RDS snapshots为一个你自己就能轮换的窗口按 GB-天付费
- pgBackRest cron jobs为只是一条 curl 的事配一套备份工具、一个配置文件、一个守护进程
- custom dump-and-rotate scripts脆弱的 bash,按 mtime 列出、排序、清理
- cron-spawning S3 backup jobs要维护生命周期策略、桶版本控制和一个 IAM 角色
- BTRFS snapshot tooling文件系统级快照,需要一台你自己掌控的宿主机
- Restic + cron一个二进制、一个仓库、一个密码文件、一份保留策略
use-cases / rolling-24h-snapshots / cta
删掉备份手册。安排 @hourly。你容器的过去 24 小时,以 24 个命名楼层存在 —— 而电梯就是一条 curl。
use-cases / rolling-24h-snapshots / related
阅读其他内容
