タイプアンロックステージ本番環境難易度シンプルジョブ状態をバックアップ対象バックエンド開発者対象DevOps & インフラサービスCron サービススナップショット Hoody の利点スナップショット時間旅行 Hoody の利点コンテナ経済学

use-cases / rolling-24h-snapshots / hero

CRON · SNAPSHOTS · ROLLING 24

直近 24 時間を 24 個のスナップショットとして保持

管理 cron エントリが @hourly で発火します。auto-h$(date +%H) という名前のスナップショットを POST します。名前は auto-h00 から auto-h23 まで循環します。1 日経つと、新しいスナップショットが前日同時刻のものを上書きします。常に直近 24 時間の状態を、毎時の粒度で保持できます。

snapshots ドキュメントを読む

containers.hoody.com · snapshots

https://containers.hoody.com/snapshots/rolling-24hlive · 24/24

階 · 直近 24h24 / 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 · curl 1 回

ローリングウィンドウ · 毎時 24 スナップショット16:00 · あと 12m で失効

−24h−12hnow

エレベーターは 24 階で停まります。昨日のあの時刻は、今日の同じ時刻に上書きされます

use-cases / rolling-24h-snapshots / mechanism

1 行の cron、1 つの命名規則

@hourly の管理エントリが alias auto-h$(date +%H) でスナップショット URL を curl します。alias はあえて衝突します。明日の 13 時には、今日の auto-h13 が置き換えられます。24 個の名前付きスロットが、自動的に回転します。

cron エントリ · @hourly

POST · cron/entries

# Hoody Cron — 毎時のスナップショットを 1 件スケジュール。
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

保持ポリシーも掃除人も存在しません。alias auto-h13 は 24 時間ごとに再利用され、それがウィンドウを回転させる仕組みです。Hoody Snapshots API は POST /api/v1/containers/[id]/snapshots でオプションの alias フィールドをサポートしており、それを再利用するだけで仕組みが完結します。

use-cases / rolling-24h-snapshots / anatomy

1 時間ぶんのローリング処理を解剖

4 ステップ、すべてが 1 回の curl の中に収まります。cron ティックからスナップショット完了まで数秒です。

0113:00:00cron ティック発火@hourly · 管理エントリ

0213:00:04スナップショット POSTalias auto-h13

0313:00:06階が確定hourly-2026-05-04-13

04+24h同じ alias が上書き掃除人は不要

各ティックは数秒で終わります。alias こそが回転のプリミティブです。24 時間後に同じ名前を再利用することで、その階のスナップショットがその場で置き換わります。

use-cases / rolling-24h-snapshots / powers

24 階建てタイムマシンの 3 つの力

バックアップのランブックを捨てて手放したものは、より安く、より誠実な形で取り戻せます。

ECONOMICS

アイドル状態のスナップショットはほとんど無料

スナップショットはディスク上でステートレスです。置いている間は CPU も RAM も消費しません。常時稼働するバックアップサービスではなく、コンテナの差分 24 個ぶんのストレージにだけ料金を払います。

GRANULARITY

1 時間という後悔の単位

14:14 に何かが起きたら、auto-h13 を復元すれば 13:00 まで戻れます。問題発生の 1 分前です。毎時の粒度は、本番ロールバックには十分細かく、台帳を埋め尽くさない程度には粗くて済みます。

OPERATIONS

保持ルールも監査もなし

書くべきライフサイクルポリシーも、用意すべき S3 バケットも、毎年のランブックレビューもありません。命名規則そのものが保持ルールです。固定 alias 集合そのものが監査記録です。

use-cases / rolling-24h-snapshots / economics

ローリングウィンドウのコスト

典型的なコンテナのスナップショットを毎時粒度で 24 個保持します。数字は Hoody Snapshots API と、毎時 1.2 GB という代表的な差分サイズに基づきます。

FLOORS RETAINED24
各時間が名前付きスロットです。1 日目以降、新しいスナップショットは毎回前日同時刻ぶんを上書きします。総数は増えません。
OF CRONTAB1 line
管理エントリ 1 件、スケジュール @hourly、コマンドは alias auto-h$(date +%H) でスナップショット URL を curl するだけ。それで回転は完結します。
JANITORS0
プルージョブも、expires_at ポリシーも、ライフサイクル設定も不要です。alias の衝突がその場でウィンドウを回転させ、何も積み上がりません。

Hoody Container Snapshots API の仕様: POST /api/v1/containers/[id]/snapshots はオプションの alias (最大 100 文字) と日数指定のオプションの失効を受け付けます。本ページではコンテナの既定スナップショット価格と、毎時取得あたり代表的な約 1.2 GB の差分を前提としています。実際のサイズはワークロードによって変わります。

use-cases / rolling-24h-snapshots / punchline

あなたのタイムマシンには 24 の階があり、エレベーターは 1 回の curl です。

before · バックアップソフトウェアafter · cron 1 行

WHAT IT USED TO LOOK LIKERDS スナップショット + ライフサイクルポリシー + S3 バケット + 年次監査可動部品が 4 つ · GB-日単位の課金 · ランブックの該当ページ

WHAT IT LOOKS LIKE NOW@hourly curl POST snapshots -d '["alias":"auto-h$(date +%H)"]'cron 1 行 · 命名規則 1 つ · 24 階

snapshots ドキュメントを読む

use-cases / rolling-24h-snapshots / replaces

これが置き換えるもの

毎時のポイントインタイムリカバリを求めたときに、つい手を伸ばす定番ツール群です。それぞれサービス料金や保持ポリシーが課金されます。cron + alias モデルでは、そのどちらも課金されません。

AWS RDS スナップショット自分で回せるウィンドウのために、GB-日単位の課金
pgBackRest cron ジョブ1 回の curl で済むことに、バックアップツールと設定ファイルとデーモン
カスタム dump-and-rotate スクリプトmtime で一覧、ソート、削除する壊れやすい bash
cron で発火する S3 バックアップジョブライフサイクルポリシー、バケットのバージョニング、維持すべき IAM ロール
BTRFS スナップショットツール自分で管理するホストを必要とする、ファイルシステムレベルのスナップショット
Restic + cronバイナリ、リポジトリ、パスワードファイル、保持ポリシーが必要

use-cases / rolling-24h-snapshots / cta

バックアップのランブックは捨てましょう。@hourly をスケジュールしてください。コンテナの直近 24 時間が、24 の名前付き階として存在します。エレベーターは 1 回の curl だけです。

snapshots ドキュメントを読む

use-cases / rolling-24h-snapshots / related

直近 24 時間を 24 個のスナップショットとして保持

1 行の cron、1 つの命名規則

1 時間ぶんのローリング処理を解剖

24 階建てタイムマシンの 3 つの力

アイドル状態のスナップショットはほとんど無料

1 時間という後悔の単位

保持ルールも監査もなし

ローリングウィンドウのコスト

これが置き換えるもの

他のユースケースを読む

1 つのサーバーで 60 のコンテナ

1 つのリンクで開発者をオンボード

オンデマンドで具現化するAPI エンドポイント

Git のようにコンピュータをブランチ化

スマホで本物の VS Code

他の AI エージェントを生成する AI エージェント

顧客ごとに 1 つのサンドボックスを自動的に

完成したプロトタイプで目覚める

電話から本番環境を緊急修復

誰でも curl できる URL に本番ログを tail

1 つのビルドを 30 の CI ワーカーへ同時にプッシュ

カフェからエージェントの思考を眺める

会議招待ではなく URL で画面を共有

2 つの curl でクラウド間で 200GB を移動

1 行でチームメイトにデータベースの状態を送信

HTTP を読むあらゆるものに LLM トークンをストリーミング

上司が参加せずに観戦できるプログレスバー

構築する必要のなかった Webhook ファンアウト

2 つの curl コマンドだけの CI キャッシュ

スクリプトにドラッグ&ドロップでアップロード

ノートパソコンから 200 人にワークショップを配信

メッセージブローカーなしのコンテナ間 IPC

電車内でエージェントを tail し、終了したら通知を受ける

2 つのターミナルで HTTP 越しのマイク

5 つのエージェント、5 つのパイプ、1 つの判定

今朝のインシデントをチーム全員で再生

今までで最速の「あのファイル送って」

ローカル LLM を実行し、フリート全体に配信

メトリクスバックエンドなしのライブメトリクスダッシュボード

完了したら自分で消える cron ジョブ

夜間マイグレーションの直前にコンテナをスナップショット

全顧客に専用 crontab を自動で

午前 3 時にエージェントを起こし、4 時に退役させる

オーケストレーターなしの日次ロールアップ

ブランチごとの crontab を、コードと一緒にデプロイ

シフトとともに失効するオンコールエスカレーション

毎時のスクレイプ、日次のダイジェスト、週次のアーカイブ — 1 つのコンテナで

顧客に自分の cron スケジュールを持ち込んでもらう

スクリプトではなくエージェントをスケジュールする

静かなジョブのためのハートビート

今朝の webhook を、明日の同じ時刻にリプレイ

空港のスマホから crontab を編集

200 件の受信箱へファンアウトするスケジュール配信

不安定なジョブを失わずにミュートする

昨日のエージェントを採点するエージェント

自分自身の引退をスケジュールするクリーンアップジョブ

SSH セッションなしで TLS 証明書を更新する

本番を壊そうとする毎週のカナリア

生かしておける余裕のある趣味プロジェクトの墓場

プルリクエストごとのプレビュー環境、月中

ベアメタル 1 台で 12 製品ポートフォリオを運営

ステージングサーバー税を撲滅

40 のクライアントサイト、1 つの家賃、1 つのダッシュボード

E2B の請求を、すでにレンタルしているベアメタルに置き換える

アイドル状態のステージングは無料、だからステージングが削除されなくなる

フリート規模で顧客ごとのサンドボックス

S3 の請求項目にならない CI キャッシュ

50 件の営業電話のための 50 のデモ環境