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), wait, 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 tout le bloc config par :

{ "source": "source_profile", "source_id": "<identifiant de votre 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.

Les mots de passe des exemples¶

Les mots de passe écrits dans ces recettes (demo-ldap, restore, demo-gitea…) sont ceux du conteneur bac à sable créé pour l'exécution, détruit à la fin. Ce ne sont jamais les mots de passe de votre serveur d'origine, et RestoreProof n'en 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 : env://MA_VARIABLE. Le runner la résout dans son propre environnement, chez vous. RestoreProof ne stocke jamais la valeur.