Le Hub · Sauvegardes
Chaque nuit,
une copie ailleurs.
Les bases de vos programmes, le coffre de secrets, la configuration : le Hub les copie vers un stockage S3 distant, à l’heure choisie, et note ce qui a réussi.
À quoi ça sert
Un serveur finit toujours par tomber : un disque, une erreur de manipulation, une mise à jour ratée. Ce jour-là, la seule question qui compte est : y a-t-il une copie, ailleurs, et de quand date-t-elle ?
Le Hub répond avec un module de sauvegarde. Il copie les données vers un stockage S3 que vous choisissez, hors du serveur, selon une planification. Chaque exécution est journalisée : statut, nombre d’éléments, volume, durée.
Ce qu’on voit à l’écran
L’écran est celui du Hub thesocle.net, au 2026-09-23.
Le bandeau du haut dit comment c’est fait : un programme autonome écrit en Go, socle-backup, qui écrit dans des formats ouverts (SQL en texte, JSON, fichiers natifs). On peut donc relire une sauvegarde sans la restaurer. Quatre boutons mènent aux destinations, aux
planifications, aux cibles et à l’historique.
Quatre tuiles. 2 destinations S3, 1 planification, 0 cible de base listée à part, et le daemon Go en état healthy.
Lancer une sauvegarde manuelle. Une case PostgreSQL cochée, un bouton. Utile pour un essai ; la vraie sauvegarde est celle de la nuit.
Les familles de données que sait traiter le module : postgres, mariadb, vault, minio, techdb, sqlite, volumes, config, metadata. L’écran porte encore des mentions du chantier de construction du module (« P4 », « P6 », « P7 ») : on se fie aux exécutions, plus bas.
Les cinq dernières exécutions, du 19 au 23 septembre. Toutes au statut ok. Chacune démarre à 3 h du matin, compte 61 ou 62 éléments, pèse une vingtaine de gigaoctets, et dure entre 51 et 84 minutes. Le volume grossit un peu chaque nuit, avec les données.
Comment on s’en sert
On donne une destination
Un stockage S3 hors du serveur : ses coordonnées et ses clés, rangées dans le coffre du Hub. On teste la destination avant de s’y fier.
On planifie
Une heure, une durée de conservation, les familles à inclure.
On laisse la nuit passer
On vérifie le lendemain : l’exécution est là, au statut ok, avec son volume et sa durée.
On surveille
Une exécution partielle ou en échec se voit dans l’historique, avec le détail de chaque élément.
Sous le capot
| Composants | le daemon Go socle-backup, piloté par le backup_worker du Hub |
| Actions MCP | create_destination, test_destination, delete_destination, list_destinations, create_schedule, delete_schedule, list_schedules, run_now, list_runs, get_run, list_database_targets, refresh_targets, purge_old_runs, get_status |
| Base d’une application | db_worker : backup_app_db, list_backups, restore_backup |
| Console | /hub/backup |
Pour vérifier une planification, on la laisse passer par son ordonnanceur plutôt que par
run_now : c’est le chemin qu’emprunte la sauvegarde de chaque nuit.
Les limites d’aujourd’hui
Un Hub neuf n’a aucune sauvegarde. Rien n’est provisionné d’office à l’installation : tant qu’on ne lui a pas donné une destination et une planification, il ne copie rien. C’est une étape de la mise en service, à ne jamais sauter.
Une sauvegarde ne vaut que si on sait la restaurer. L’exercice de restauration se prévoit à part, sur une machine d’essai.