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 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à. 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 pour cibler ce runner depuis certains plans. Si vos sauvegardes sont sur le disque local, déclarez ici les répertoires à monter dans le conteneur : l'assistant les ajoute à la commande.
• Déploiement — l'assistant affiche la clé API et la commande docker run complète.

Ne recopiez pas l'adresse de cette capture

Cette capture a été prise sur une pile de test : RESTOREPROOF_URL 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é 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é), un bucket GCS, un conteneur Azure, une URL HTTP, ou un répertoire local — c'est-à-dire, pour un runner Docker, un chemin dans le conteneur, celui que vous avez monté à l'étape précédente. C'est la confusion la plus fréquente : le chemin de l'hôte n'existe pas pour le runner.

Une source ne contient jamais d'identifiants. L'authentification est résolue côté runner : variables d'environnement, fichier de credentials, rôle IAM de l'instance.

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

4. Écrire un plan

Plans de test → Créer un plan de test. L'assistant propose des modèles — PostgreSQL, MySQL, WordPress, archive de fichiers — ou un plan personnalisé. Un modèle vous pose deux ou trois questions (format de la sauvegarde, nom du fichier de dump) et é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) ou attendre qu'un service réponde (wait). Le conteneur doit démarrer avant l'étape de restauration qui le vise.

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é.

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

Le premier essai d'un plan dont les sondes n'ont encore aucun seuil échoue, volontairement. Une sonde à qui on ne demande rien ne prouve rien, et le produit refuse de faire passer ça pour un succès.

En échouant, elle rend ce qu'elle a mesuré.

Sur cette capture : le canari a parcouru l'arborescence restaurée, trouvé 804 fichiers dans 6 répertoires, 419 580 727 octets au total — et l'a dit en rouge, en listant les contrôles qu'on peut lui demander. L'écran le formule comme il faut : ce rouge est l'étape de réglage, pas une panne.

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 601 690 pour 419 580 727 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.

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 :

• Planifications — une expression cron et un fuseau horaire, avec des choix tout faits (chaque nuit à 2 h, chaque semaine le dimanche, chaque mois le 1er). Vous pouvez épingler un runner ou laisser la sélection automatique.
• Webhooks — une URL à appeler à la fin de votre job de sauvegarde. Le produit vous donne le bout de script pour restic, borg, rclone, Duplicati, Veeam, ou un simple curl. C'est le déclenchement le plus juste : le test porte sur la sauvegarde qui vient d'être produite.

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.