Soixante conteneurs sur un seul serveur
Une seule machine bare-metal fait tourner des dizaines à des centaines de conteneurs Hoody. La déduplication KSM et BTRFS rend le coût marginal quasi nul.
Conteneurs·Snapshots
TYPEDébloqué
ÉTAPEProduction
DIFFICULTÉSimple
MÉTIERSauvegarder un état
POURDevs backend
POURDevOps et infra
SERVICESCron
SERVICESSnapshots
POURQUOI HOODYVoyage temporel par snapshot
POURQUOI HOODYÉconomie des conteneurs
TYPEDébloqué
ÉTAPEProduction
DIFFICULTÉSimple
MÉTIERSauvegarder un état
POURDevs backend
POURDevOps et infra
SERVICESCron
SERVICESSnapshots
POURQUOI HOODYVoyage temporel par snapshot
POURQUOI HOODYÉconomie des conteneurs
TYPEDébloqué
ÉTAPEProduction
DIFFICULTÉSimple
MÉTIERSauvegarder un état
POURDevs backend
POURDevOps et infra
SERVICESCron
SERVICESSnapshots
POURQUOI HOODYVoyage temporel par snapshot
POURQUOI HOODYÉconomie des conteneurs
TYPEDébloqué
ÉTAPEProduction
DIFFICULTÉSimple
MÉTIERSauvegarder un état
POURDevs backend
POURDevOps et infra
SERVICESCron
SERVICESSnapshots
POURQUOI HOODYVoyage temporel par snapshot
POURQUOI HOODYÉconomie des conteneurs
use-cases / rolling-24h-snapshots / hero
CRON · SNAPSHOTS · 24 GLISSANTES
Gardez les 24 dernières heures sous forme de 24 snapshots
Une entrée cron managée se déclenche @hourly. Elle POST un snapshot nommé auto-h$(date +%H). Les noms tournent : auto-h00 jusqu'à auto-h23. Après une journée, chaque nouveau snapshot écrase celui d'hier à la même heure — et vous avez toujours les 24 dernières heures de state, retenues à granularité horaire.
containers.hoody.com · snapshots
https://containers.hoody.com/snapshots/rolling-24hlive · 24/24
étages · 24 dernières h24 / 24
snapshot sélectionnéauto-h13
id du snapshot1.24 GB
hourly-2026-05-04-13// GET /snapshots — record complet :
{ "name": "hourly-2026-05-04-13", "alias": "auto-h13", "created_at": "13:00:04Z", "size": 1331691520 }
PATCH · 1 curl
fenêtre glissante · 24 snapshots horaires16:00 · expire dans 12m
−24h−12hnow
l'ascenseur s'arrête à 24 étages — l'heure d'hier est écrasée par celle d'aujourd'hui
use-cases / rolling-24h-snapshots / mechanism
Une ligne de cron, une convention de nommage
Une entrée managée @hourly curl l'URL des snapshots avec l'alias auto-h$(date +%H). L'alias entre en collision intentionnellement : à 13h demain, le auto-h13 d'aujourd'hui est remplacé. Vingt-quatre slots nommés, rotation automatique.
entrée cron · @hourly
POST · cron/entries# Hoody Cron — planifie un snapshot horaire. 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" }'
le nom de l'heure est la clé de rotation
URL snapshot · ce que le cron tape réellement
POST · containers/[id]/snapshots# À 13:00 le cron s'exécute — voici la requête envoyée : curl -X POST \ api.hoody.com/api/v1/containers/$ID/snapshots \ -H "Authorization: Bearer $TOKEN" \ -d '{"alias": "auto-h13"}' # Réponse : → 200 OK · hourly-2026-05-04-13 created in 6s
Il n'y a pas de policy de rétention et pas de janitor — l'alias auto-h13 est réutilisé toutes les 24 heures, et c'est ce qui fait tourner la fenêtre. L'API Hoody Snapshots accepte un champ alias optionnel sur POST /api/v1/containers/[id]/snapshots ; le réutiliser, c'est tout le mécanisme.
use-cases / rolling-24h-snapshots / anatomy
Anatomie d'une heure glissante
Quatre étapes, toutes dans un seul curl. Du tick cron au snapshot en quelques secondes.
0113:00:00Tick cron déclenché@hourly · entrée managée
0213:00:04Snapshot POSTéalias auto-h13
0313:00:06Étage matérialiséhourly-2026-05-04-13
04+24hLe même alias l'écrasepas de janitor nécessaire
Chaque tick prend des secondes. L'alias est la primitive de rotation — en réutilisant le même nom 24 heures plus tard, le snapshot à cet étage est remplacé sur place.
use-cases / rolling-24h-snapshots / powers
Trois pouvoirs d'une machine à remonter le temps à 24 étages
Ce que vous perdez en supprimant le runbook backup, vous le récupérez sous une forme moins chère et plus honnête.
ÉCONOMIE
Les snapshots inactifs ne coûtent presque rien
Les snapshots sont sans state sur disque ; ils ne brûlent ni CPU ni RAM en restant là. vous payez pour le stockage de 24 copies du diff du conteneur, pas pour un service de backup qui tourne tout le temps.
GRANULARITÉ
Une heure est l'unité de regret
Quand quelque chose foire à 14:14, vous restaurez auto-h13 et vous voilà à 13:00 — une minute avant le démarrage du problème. L'heure est assez fine pour le rollback prod et assez large pour ne pas noyer le ledger.
OPÉRATIONS
Pas de règles de rétention, pas d'audit
Pas de lifecycle policy à écrire, pas de bucket S3 à provisionner, pas de revue annuelle de runbook. La convention de nommage est la règle de rétention. L'ensemble fixe d'alias est l'audit.
use-cases / rolling-24h-snapshots / economics
Ce que coûte la fenêtre glissante
Vingt-quatre snapshots d'un conteneur typique, retenus à granularité horaire. Les chiffres viennent de l'API Hoody Snapshots et d'un diff représentatif de 1.2 GB par heure.
- ÉTAGES RETENUS24
Chaque heure est un slot nommé. Après le premier jour, chaque nouveau snapshot écrase celui d'hier à la même heure — le compte ne grossit jamais.
- DE CRONTAB1 ligne
Une entrée managée, schedule @hourly, commande qui curl l'URL des snapshots avec l'alias auto-h$(date +%H). C'est toute la rotation.
- JANITORS0
Pas de job de prune, pas de policy expires_at, pas de config lifecycle. La collision d'alias fait tourner la fenêtre sur place ; rien n'accumule.
Selon l'API Hoody Conteneur Snapshots : POST /api/v1/containers/[id]/snapshots accepte un alias optionnel (max 100 caractères) et une expiration optionnelle en jours. Cette page suppose le pricing snapshot par défaut des conteneurs et un diff représentatif de ~1.2 GB par capture horaire ; vos tailles varieront selon la charge.
use-cases / rolling-24h-snapshots / punchline
votre machine à remonter le temps a 24 étages et l'ascenseur est un curl.
avant · logiciel de backupaprès · une ligne de cron
À QUOI ÇA RESSEMBLAITSnapshots RDS + lifecycle policy + bucket S3 + audit annuelquatre pièces mobiles · facturation par GB-jour · page de runbook
À QUOI ÇA RESSEMBLE MAINTENANT@hourly curl POST snapshots -d '{"alias":"auto-h$(date +%H)"}'une ligne de cron · une convention de nommage · 24 étages
use-cases / rolling-24h-snapshots / replaces
Ce que ça remplace
Les outils standards qu'on attrape pour de la récupération horaire à un point dans le temps. Chacun vous facture un service ou une policy de rétention. Le modèle cron + alias ne vous facture ni l'un ni l'autre.
- Snapshots AWS RDSFacturation par GB-jour pour une fenêtre que vous pouvez faire tourner vous-même
- Jobs cron pgBackRestUn outil de backup, un fichier de config et un daemon pour ce qui tient en un curl
- Scripts custom dump-and-rotateDu bash fragile qui liste, trie et purge par mtime
- Jobs cron de backup S3Lifecycle policies, versioning de bucket et un rôle IAM à maintenir
- Tooling de snapshot BTRFSSnapshots filesystem qui exigent un host que vous contrôles
- Restic + cronUn binaire, un repo, un fichier mot de passe et une policy de rétention
use-cases / rolling-24h-snapshots / cta
Supprime le runbook de backup. Planifie le @hourly. Les 24 dernières heures de votre conteneur existent comme 24 étages nommés — et l'ascenseur est un seul curl.
use-cases / rolling-24h-snapshots / related