Référence¶
Cette partie décrit ce que le produit fait, exactement. Chaque variable, chaque valeur par défaut et chaque route qui suit a été relue dans le code avant d'être écrite ici.
Ce n'est pas un guide de démarrage : pour découvrir le produit, lisez le parcours complet, puis les recettes. Revenez ici quand vous voulez le détail d'un champ.
- Sondes — les dix sondes, leurs variables, ce qu'elles affirment.
- Moteur de restauration — les neuf types d'étapes.
- API — les routes HTTP.
- Notifications — Slack, Teams, Discord, Telegram, Matrix, e-mail et webhook signé, les événements et les tentatives.
- Compte et équipe — inscription, rôles, invitations, double authentification.
- Données et conservation — ce que nous enregistrons, et combien de temps.
- Vérifier un rapport signé — pour l'auditeur qui reçoit une preuve et doit la contrôler lui-même.
Les objets du produit¶
RestoreProof manipule six objets. Ils s'emboîtent toujours dans le même ordre.
| Objet | Ce que c'est | Où il vit |
|---|---|---|
| Organisation | Votre compte. Tout le reste lui appartient. | Control Plane |
| Source | La description publique d'un dépôt de sauvegarde (type, point d'accès, préfixe). Aucun secret. | Control Plane |
| Plan de restauration | La recette : les étapes de restauration, puis les sondes. | Control Plane |
| Runner | L'agent que vous installez chez vous. Le seul à voir vos sauvegardes et vos secrets. | Votre infrastructure |
| Exécution (run) | Un passage du plan par un runner, à un instant donné. | Déclenchée par le Control Plane, exécutée par le runner |
| Rapport | Le résultat signé de cette exécution. | Control Plane |
Comment ils s'articulent¶
- Vous décrivez une source et écrivez un plan dans l'interface.
- Un runner installé chez vous ouvre un canal vers le Control Plane et y reste connecté.
- Une exécution est créée — à la main, par une planification, ou par un webhook. Le Control Plane la propose au runner.
- Le runner exécute les étapes du plan : il télécharge la sauvegarde, la décompresse, démarre un bac à sable, y restaure les données.
- Il lance ensuite les sondes, chacune dans son propre conteneur jetable.
- Il produit un rapport signé en Ed25519 et l'envoie au Control Plane.
- Il détruit le bac à sable, ses volumes et son espace de travail.
La ligne que rien ne franchit¶
Le runner est le seul composant qui lit vos sauvegardes, connaît vos secrets et
restaure vos volumes. Le Control Plane ne reçoit que le rapport : des états
(PASS, WARN, FAIL), des mesures numériques, des noms d'objets et des
empreintes.
Concrètement, le Control Plane ne stocke jamais :
- le contenu d'une sauvegarde ;
- un mot de passe, une clé S3, un jeton.
Une source décrit où est la sauvegarde, du point de vue du runner : un
point d'accès et un seau pour S3, un chemin de montage comme /mnt/sauvegardes
pour un dépôt local. Cette configuration est bien enregistrée dans RestoreProof
et redescendue au runner avec le plan — sans elle, le runner ne saurait pas quoi
ouvrir. Les chemins de votre hôte, eux, restent dans votre navigateur : ce que
vous saisissez dans l'assistant de déploiement sert à écrire votre commande de
démarrage, et n'est jamais envoyé.
La référence du secret qui ouvre la source — env://S3_SECRET_KEY, par
exemple — est enregistrée elle aussi : c'est un nom, pas un accès. Seule la
valeur derrière ce nom reste sur le runner, dans son environnement ou son
fichier de configuration, et n'en sort jamais.
Une référence s'écrit toujours sous l'une de ces trois formes :
env://NOM_DE_VARIABLE, file://nom_de_fichier, static://cle. Toute autre
valeur est refusée à l'enregistrement, y compris — et surtout — un secret écrit
en clair.
Le détail de ce qui est enregistré, et pour combien de temps, est dans Données et conservation.
L'espace de travail¶
Toutes les étapes d'une exécution partagent un répertoire temporaire, l'espace
de travail. Le moteur de restauration y écrit ; les sondes le voient monté en
lecture seule sur /workspace.
C'est la seule chose qu'une sonde et une étape ont en commun : une sonde ne sait rien du plan qui l'a précédée, elle ne connaît que le contenu de ce répertoire et les variables d'environnement qu'on lui a passées.
L'espace de travail est supprimé à la fin de l'exécution, quel qu'en soit le résultat.
Le verdict d'une exécution¶
Chaque sonde écrit /out/result.json avec un état parmi trois :
| État | Signification | Code de sortie du conteneur |
|---|---|---|
PASS |
Tout ce qui était demandé est vérifié. | 0 |
WARN |
Vérifié, avec une réserve. | 0 |
FAIL |
Une vérification a échoué, ou n'a pas pu être faite. | 1 |
Une sonde à qui on ne demande rien ne rend pas forcément PASS : plusieurs
sondes échouent délibérément dans ce cas. Voir
le contrat d'assertion.