Choisir sa recette

Une recette est un plan de test complet : les étapes qui restaurent votre sauvegarde dans un bac à sable jetable, et les sondes qui vérifient ce qui en est sorti. Chaque recette est donnée en JSON, prête à coller.

J'ai ceci → allez là

Ce que vous sauvegardez	Recette
Un dump PostgreSQL (.sql, .sql.gz, .dump)	PostgreSQL
Un dump MySQL ou MariaDB (mysqldump)	MySQL
Une archive tar.gz / zip de fichiers	Fichiers et archives
Une archive que vous ne voulez pas décompresser	Vérifier l'archive sans l'ouvrir
Un site WordPress (base + wp-content)	WordPress
Gitea, Docmost, Vaultwarden (base + fichiers)	Applications auto-hébergées
Une sauvegarde PocketBase (ZIP de pb_data)	PocketBase
Un annuaire LDAP (export LDIF)	LDAP
Une base MongoDB (mongodump)	MongoDB
Des certificats TLS (fichiers PEM)	Certificats

Votre technologie n'est pas dans la liste : partez de la recette la plus proche. Une base relationnelle se restaure comme PostgreSQL, un dossier de données comme une archive de fichiers, une application qui redémarre sur son répertoire comme PocketBase.

Ce qu'une recette contient

Un plan est un document JSON avec deux clés, et rien d'autre :

• steps — ce qu'il faut faire pour obtenir la donnée restaurée : fetch (récupérer), unpack (décompresser), start_sandbox (démarrer un conteneur), exec_in_sandbox (préparer le conteneur), restore_postgres, restore_mysql, restore_mongo, restore_ldap. Il n'y a pas d'autre type d'étape.
• probes — ce qui est vérifié une fois la restauration faite. Chaque sonde tourne dans son propre conteneur, détruit après.

Pour l'utiliser : créez un plan, ouvrez l'écran d'édition, onglet JSON (expert), collez, enregistrez.

Adapter le bloc fetch

Dans les recettes qui suivent, l'étape fetch désigne un dossier local visible par le runner :

{
  "source": "local",
  "path": "/backups/mon-app",
  "file_pattern": "dump_*.sql.gz",
  "selection_strategy": "latest_modified",
  "max_age": "26h",
  "output": "dump.sql.gz"
}

Si vous avez déclaré une source (S3, MinIO, HTTP) dans RestoreProof, remplacez l'emplacement — source, path — par une référence à cette source. Le profil apporte le chemin (ou le bucket S3), le motif de fichier et la stratégie de sélection que vous y avez saisis :

{
  "source": "source_profile",
  "source_id": "<identifiant de votre source>",
  "max_age": "26h",
  "output": "dump.sql.gz"
}

Les clés que vous laissez dans l'étape l'emportent sur celles du profil. Gardez donc output — les étapes suivantes désignent le fichier par ce nom — et max_age, qui appartient au plan et non à la source.

max_age fait échouer l'exécution quand la sauvegarde trouvée à la source est plus vieille que ce délai. C'est la seule vérification qu'un test de restauration ne peut pas déduire du contenu : une sauvegarde qui a cessé d'être produite il y a trois mois se restaure parfaitement.

Les seuils ne se comptent pas à la main

Toutes les recettes contiennent des nombres : 100 articles, 6 comptes, 50 fichiers. Ne recopiez pas les nôtres et n'allez pas compter sur votre infrastructure.

Lancez un essai. Il restaure votre sauvegarde et compte ce qu'elle contient réellement. L'écran vous propose alors chaque seuil 5 % en dessous de la valeur mesurée, jamais en dessous de 1, avec l'opérateur gte (« au moins »). Vous corrigez si besoin, vous appliquez, vous enregistrez.

Les 5 % sont une marge volontaire : sans elle, la première sauvegarde qui contient un fichier de moins passe au rouge, et trois fausses alertes suffisent à ce que plus personne ne lise les alertes. L'opérateur n'est jamais eq : une sauvegarde qui grossit, c'est normal.

Pour MongoDB, l'essai propose en plus le nom de la base et celui de la collection : la sonde liste ce qu'elle a trouvé dans le bac à sable, et vous reprenez le nom exact d'un clic au lieu de le deviner. Et si l'archive ne contient pas la base nommée dans le plan, l'étape de restauration s'arrête tout de suite en listant ce qu'elle contient vraiment.

Le mot de passe du bac à sable

Les recettes ne montrent aucun mot de passe pour le conteneur bac à sable : il n'y en a pas dans le plan, nulle part. Le runner reconnaît le type de conteneur qu'il démarre et fabrique lui-même les identifiants dont il a besoin, à chaque exécution. Il n'y a rien à choisir ni à saisir. Cette valeur ne sort jamais du runner, elle est identique partout où le conteneur est visé dans une même exécution, et elle disparaît avec lui à la fin. Elle n'a aucun rapport avec les mots de passe de votre serveur d'origine, dont RestoreProof n'a pas besoin : la restauration recrée les comptes tels que la sauvegarde les contient.

Quand une sonde a besoin d'un vrai secret (le mot de passe d'un compte administrateur de l'application restaurée, par exemple), écrivez une référence plutôt que la valeur, sous l'une de ces trois formes :

Référence	Ce que le runner lit
env://MA_VARIABLE	La variable d'environnement MA_VARIABLE du runner
file://ma_cle	Le fichier ma_cle dans le dossier des secrets du runner
static://ma_cle	La clé ma_cle de la table de secrets statiques du runner

Le runner la résout chez vous, dans son propre environnement. RestoreProof ne stocke jamais la valeur.