backup.overview.ecranLes sauvegardes du Hub vers un stockage S3 distant : bases, coffre, fichiers. On y lance un backup et on suit les derniers passages.
Voir l'élément dans l'écran : backup/overview
Le Hub ne sauvegarde pas lui-même. Il confie le travail à un démon autonome, socle-backup,
écrit en Go, qui tourne à côté de lui. Le Hub tient le registre : les destinations S3, les
planifications, l'historique de chaque passage et la liste de ce qu'il contenait.
Les fichiers produits sont dans des formats ouverts : SQL en texte, JSON, fichiers tels quels. On peut donc relire un seul schéma sans tout restaurer.
L'écran se lit de haut en bas :
Quatre boutons mènent aux écrans de détail : Destinations, Schedules, Cibles DB et Historique.
GET /hub/backup → BackupService.getWorkerStatus(), listRuns(5) et availableFamilies().
C'est le même service que l'action backup_worker.get_status.
| Donnée | D'où elle vient |
|---|---|
| Destinations S3 | backup.z_s3_destinations (nombre de lignes) |
| Schedules | backup.z_schedules |
| Cibles DB | backup.z_database_targets |
| Daemon Go | un appel de santé au démon, à chaque affichage |
| 5 derniers runs | backup.z_runs, les plus récents d'abord |
Toutes les opérations existent en actions du worker backup_worker : run_now,
list_runs, get_run, create_destination, test_destination, create_schedule,
purge_old_runs, refresh_targets… Elles se jouent par MCP (POST /mcp) ou par REST
(/api/actions).
Plusieurs textes de l'écran datent des premières phases du chantier et ne disent plus vrai :
postgres est branché côté daemon » : les passages planifiés comptent plus de
cent éléments, et non les seuls schémas PostgreSQL ;run_now avec id_s3_destinations).