Le parcours complet

De la création du compte à la première preuve signée. Comptez une heure la première fois, l'essentiel du temps passant à écrire le plan et à le calibrer.

Avant de commencer, vérifiez que vous avez bien ce qu'il vous faut.

1. Le tableau de bord

Juste après l'inscription, tout est à zéro. Le tableau de bord affiche d'abord une Prise en main en quatre étapes cochables — déployer un runner, connecter une source de backup, créer un plan de restauration, lancer votre premier test — qui disparaît une fois les quatre faites.

Juste en dessous, Que voulez-vous faire ? propose quatre raccourcis — Ajouter un backup, Créer un plan de test, Automatiser, Connecter mon système de backup — qui sont les quatre assistants du produit.

Le score de restaurabilité et les exécutions de preuve récentes de cette capture sont ceux d'un compte qui tourne déjà — la Prise en main y a donc déjà disparu. Le vôtre sera vide jusqu'à votre première exécution.

Commencez par le runner : sans lui, rien ne peut s'exécuter.

2. Déployer un runner

Parc de runners → Ajouter un runner. L'assistant compte quatre étapes : Plateforme, Configuration, Déploiement, Connexion.

• Plateforme — Docker ou Kubernetes. Le binaire seul reste annoncé « à venir » dans l'assistant.
• Configuration — un nom (runner-dc-paris-01, quelque chose que vous reconnaîtrez dans six mois) et, en option, des labels : des étiquettes libres qui vous aident à reconnaître ce runner dans le parc. Si vos sauvegardes sont sur le disque local, déclarez ici les répertoires à monter dans le conteneur : l'assistant les ajoute à la commande. La même étape affiche ce que le runner aura le droit d'atteindre : les hôtes de vos sources HTTP et S3, et les dossiers de vos sources locales et des volumes montés. Ces deux listes sont préremplies, modifiables, et reprises dans la commande (voir ce que le runner a le droit d'atteindre).
• Déploiement — l'assistant affiche la clé API et la commande complète à exécuter : docker run pour Docker, ou kubectl create suivi de helm install pour Kubernetes — celle qui correspond à la plateforme choisie à la première étape.

Sur Kubernetes, la même étape écrit la création du namespace, du Secret pour la clé d'API, puis le helm install :

Ne recopiez pas l'adresse de ces captures

Les deux captures ont été prises sur une pile de test : l'adresse du control plane y vaut http://backend:9090, un nom qui n'existe que dans ce réseau Docker-là. La commande que votre écran affiche porte l'adresse publique du canal du control plane, en https://. Copiez la commande de votre écran, jamais celle d'une documentation. La clé d'API y est masquée, comme sur la vôtre tant que vous ne l'avez pas copiée.

La clé API n'est affichée qu'une fois. Copiez la commande, exécutez-la sur votre serveur, et l'assistant passe à Connexion : il attend que le runner se manifeste.

Un runner qui a coupé sa connexion, ou qui n'a plus donné signe de vie depuis 90 secondes, passe hors ligne ici. C'est le premier endroit à regarder quand une exécution ne démarre pas.

3. Déclarer une source

Sources → Ajouter une source. Une source dit où sont les sauvegardes : un bucket S3 (ou MinIO, Wasabi, avec un endpoint personnalisé), une URL HTTP, ou un répertoire local — c'est-à-dire un chemin vu par le runner, celui que vous avez monté à l'étape précédente (dans le conteneur Docker, ou dans le pod Kubernetes). C'est la confusion la plus fréquente : le chemin de l'hôte n'existe pas pour le runner.

L'assistant demande aussi un mode de sélection du backup : le dernier fichier par date, le dernier par nom (tri alphabétique), ou un fichier précis. Les deux premiers acceptent un motif de filtrage (*.sql.gz), et évitent de réécrire le plan à chaque nouvelle sauvegarde ; le troisième réclame le chemin ou la clé exacte de l'objet.

Une source ne contient jamais la valeur d'un identifiant. Pour un bucket S3, l'assistant vous laisse deux choix.

Références de secrets : deux champs, la clé d'accès et la clé secrète. Pour chacun, une liste déroulante dit où le runner va chercher, et un champ donne le nom.

Choix de la liste	Ce que le runner lit
Variable d'environnement du runner	La variable de ce nom dans son propre environnement
Fichier dans le dossier des secrets du runner	Le fichier de ce nom dans son dossier de secrets
Clé de la table statique du runner	L'entrée de ce nom dans sa configuration

Une fois la référence choisie ici, c'est sur le runner que la valeur doit être posée : Fournir les secrets au runner montre comment, pour chaque plateforme de déploiement.

HashiCorp Vault et SOPS figurent dans la liste, grisés : à venir.

Chaîne d'identification par défaut du runner : aucune référence n'est enregistrée. Le runner utilise ce qu'il trouve déjà sur sa machine, dans l'ordre — les variables AWS_ACCESS_KEY_ID et AWS_SECRET_ACCESS_KEY, le fichier ~/.aws/credentials, puis le rôle IAM de l'instance. C'est le choix naturel sur EC2 ou EKS.

Dans les deux cas, aucun champ n'accepte une valeur de secret, et le serveur refuse une source qui en contiendrait une.

Pour une source HTTP, le même bloc Identifiants propose deux choix : En-tête Authorization, qui ajoute un champ Référence de l'en-tête Authorization (le runner en fait l'en-tête Authorization), et Aucune authentification, le choix par défaut, pour une URL publique. Comme pour S3, aucun champ n'accepte la valeur elle-même : c'est une référence, que le runner résout chez lui, jamais enregistrée dans RestoreProof. Un en-tête autre qu'Authorization continue de se déclarer dans l'étape fetch du plan, sous headers.

Une source n'est pas obligatoire pour commencer : une étape fetch peut désigner directement un répertoire local.

Google Cloud Storage et Azure Blob Storage : à venir.

4. Écrire un plan

Plans de test → Créer un plan de test. L'assistant propose des modèles — PostgreSQL, MySQL, MongoDB, WordPress (complet ou base seule), OpenLDAP, 389 Directory Server, lldap, PocketBase, archive de fichiers — ou un plan personnalisé. Un modèle vous pose entre trois et une douzaine de questions selon la famille — version de l'image du bac à sable, format de la sauvegarde, nom du fichier de dump, âge maximum toléré, et pour une base ou un annuaire le nom de la base, le filtre de recherche et le nombre minimum d'entrées attendues — puis écrit le plan pour vous. Vous éditez ensuite tout.

Un plan a deux moitiés.

Les étapes de restauration, exécutées dans l'ordre.

Le schéma habituel est : télécharger (fetch) → décompresser (unpack) → démarrer le bac à sable (start_sandbox) → restaurer dedans (restore_postgres, restore_mysql, restore_mongo, restore_ldap). Le conteneur attend d'être sain avant que l'étape de restauration qui le vise ne démarre.

Les sondes de vérification, exécutées après la restauration, chacune dans son conteneur.

C'est ici que se joue la valeur du produit. Une sonde qui se contente de constater qu'un fichier existe ne prouve pas grand-chose ; une sonde qui compte les lignes d'une table, ouvre une session avec un mot de passe restauré, ou interroge l'API de l'application redémarrée, prouve quelque chose.

L'onglet JSON (expert) donne accès au document complet, pour tout ce que le formulaire n'expose pas. Les recettes sont des documents prêts à coller dedans.

Vient alors la question que tout le monde se pose : quelles valeurs je mets dans ces seuils ?

5. Essayer le plan

Ne devinez pas. Cliquez sur Tester.

Un essai exécute, pour de vrai, sur votre runner, le plan tel qu'il est à l'écran — modifications non enregistrées comprises, et même s'il n'a jamais été enregistré.

Le bouton Tester est aussi sur la page du plan enregistré : vous relancez un essai sans repasser par l'éditeur. Les seuils mesurés ne sont proposés que dans l'éditeur, puisque c'est là qu'on les écrit dans le plan.

Quatre choses à savoir, et l'écran les répète :

• Un essai ne compte pas dans votre quota mensuel et ne produit jamais de preuve signée. C'est une répétition, pas une pièce à conviction. Il reste dans l'historique des exécutions, marqué Essai, jusqu'à ce que vous le supprimiez.
• Pas de journal en direct. Le runner ne remonte que l'avancement, étape par étape. Les journaux des sondes n'arrivent qu'à la fin, avec le résultat.
• « Arrêter d'attendre » n'interrompt rien. Cela ferme votre attente ici ; l'essai va jusqu'au bout sur votre machine.
• L'essai a une adresse. Rechargez la page, revenez plus tard, vous le retrouvez. Réappuyer sur Tester en lancerait un deuxième.

Les essais sont plafonnés à 30 par jour et par organisation, remis à zéro à minuit UTC.

Calibrer les seuils

Une sonde à qui on ne demande rien ne prouve rien : le produit refuse de faire passer ça pour un succès. Le premier essai d'un plan dont les sondes n'ont encore aucun seuil ne rend donc ni vert ni rouge, mais un état à part, Mesuré. La sonde a compté, elle n'a rien vérifié — et elle vous rend ce qu'elle a compté.

Sur cette capture : le canari a parcouru l'arborescence restaurée et trouvé 804 fichiers dans 6 répertoires, 419 595 374 octets au total. L'écran le dit sans ambiguïté : rien n'a échoué, c'est l'étape de réglage.

Le bloc Régler les seuils avec ces mesures propose alors ces chiffres comme seuils, et 5 % en dessous de la valeur mesurée : 763 pour 804 fichiers, 398 615 605 pour 419 595 374 octets. Jamais en dessous de 1.

Cette marge n'est pas de la prudence décorative. Sans elle, la première sauvegarde qui contient un fichier de moins passe au rouge. Un client qui reçoit trois fausses alertes cesse de lire les alertes, et la quatrième — la vraie — passe inaperçue. Le seuil est là pour attraper l'effondrement (douze mille fichiers tombés à quarante, tous les fichiers présents mais vides), pas la respiration normale d'une sauvegarde.

Corrigez les valeurs proposées si vous en savez plus que l'essai, puis Utiliser ces valeurs comme seuils. Elles sont écrites dans le plan à l'écran : il reste à l'enregistrer.

Pour MongoDB, l'essai propose aussi la base et la collection, pas seulement le seuil : la sonde liste ce qu'elle a trouvé dans le bac à sable — les collections et leur nombre de documents, ou les autres bases du serveur si celle du plan est vide — et l'écran vous laisse reprendre le nom exact d'un clic. C'est le moment où l'on découvre qu'on avait écrit orders là où la sauvegarde dit commandes.

Et si l'archive ne contient pas du tout la base nommée dans le plan, ce n'est plus la sonde qui le dit à la fin : l'étape de restauration MongoDB échoue tout de suite, en listant ce que l'archive contient vraiment.

Relancez un essai. Il doit être vert.

6. Automatiser

Un plan qu'on lance à la main est un plan qu'on oublie. Deux façons de le faire tourner tout seul :

• Une planification. Le raccourci Automatiser va au plus court : un plan, puis un choix tout fait — chaque nuit (2 h du matin, recommandé pour les bases), chaque semaine (le dimanche), chaque mois (le 1er) ou personnalisé — avec l'heure et le fuseau horaire. L'écran Planifications donne la version complète : les mêmes fréquences plus l'expression cron brute, et le choix d'épingler un runner ou de laisser la sélection automatique.
• Un webhook — une URL à appeler à la fin de votre job de sauvegarde. C'est le déclenchement le plus juste : le test porte sur la sauvegarde qui vient d'être produite. L'assistant Connecter vous donne le bout de script à coller pour restic, borg, rclone, Duplicati, Veeam, ou un simple curl, puis propose de tester la connexion — ce test envoie un vrai appel et démarre une exécution réelle, décomptée de votre quota mensuel.

7. Lire la preuve

Une exécution réelle, elle, compte dans le quota et produit un rapport signé.

L'historique distingue les exécutions des essais (badge Essai) et indique le déclencheur : manuel ou planifié.

Le rapport donne, sonde par sonde, le verdict et la mesure qui le fonde — « l'arborescence restaurée contient 804 fichiers, 763 requis au minimum ». C'est ce qui distingue une preuve d'un feu vert : on peut la relire, la contester, la comparer à celle du mois dernier.

Télécharger le rapport de preuve produit le fichier signé. N'importe qui peut le vérifier sur la page publique /verify de l'application, sans compte et sans rien nous envoyer.

Et ensuite

• Reprenez le même parcours pour chaque famille de sauvegarde : les recettes donnent des plans prêts à coller.
• Quand une exécution échoue, le dépannage liste les erreurs réelles et leur cause.
• Après quelques passages verts, relevez vos seuils au niveau réellement observé : un plancher trop bas attrape l'effondrement, pas la dérive.