Tester une sauvegarde

Tant qu’une sauvegarde n’a pas été restaurée, rien ne prouve qu’elle fonctionne. La tester ne touche pas à votre instance, mais vous ne pouvez pas pour autant relancer docker compose up : le fichier compose fixe son nom de projet, et un second lancement recréerait la pile en service au lieu d’en monter une copie à côté. Construisez l’image sous un nom de votre choix et lancez les deux conteneurs à la main.

Monter une copie à côté de votre instance

1. Un réseau et une base de données rien que pour ce test.

   docker network create badlen-restore-test
   docker run -d --name badlen-restore-db --network badlen-restore-test \
     -e POSTGRES_USER=rt -e POSTGRES_PASSWORD=rt -e POSTGRES_DB=rt \
     -v badlen-restore-test-pgdata:/var/lib/postgresql postgres:18-alpine

2. L’application, sur un port libre. Elle applique elle-même les migrations avant de démarrer : il n’y a pas d’étape séparée pour le schéma. Lancée à la main, elle attend l’adresse dans WEB_ORIGIN, le nom que le fichier compose donne à PUBLIC_URL.

   docker build -t badlen-restore-test -f Dockerfile.api --target runtime .
   docker run -d --name badlen-restore-app --network badlen-restore-test -p 8099:3001 \
     -e DATABASE_URL='postgresql://rt:rt@badlen-restore-db:5432/rt?schema=public' \
     -e JWT_ACCESS_SECRET="$(openssl rand -hex 32)" \
     -e SECRET_ENCRYPTION_KEY="$(openssl rand -base64 32)" \
     -e WEB_ORIGIN=http://localhost:8099 \
     badlen-restore-test

3. Ouvrez http://localhost:8099, créez un compte avec des identifiants quelconques et importez votre fichier.

4. Supprimez tout. Rien ne doit rester après le test, pas même l’image : c’est une copie de votre instance de près de 800 Mo, et c’est elle qu’on oublie le plus facilement, parce qu’elle n’apparaît pas dans la liste des conteneurs.

   docker rm -f badlen-restore-app badlen-restore-db
   docker volume rm badlen-restore-test-pgdata
   docker network rm badlen-restore-test
   docker rmi badlen-restore-test

Les deux secrets de la commande

Les deux secrets de ce docker run sont générés plutôt que saisis à la main, surtout celui d’accès : au démarrage, l’application refuse un JWT_ACCESS_SECRET de moins de 16 caractères, et le conteneur s’arrête aussitôt, après avoir appliqué les migrations. Plus rien n’écoute alors sur le port 8099 : la page que vous ouvrez ne répond pas, et seul docker logs badlen-restore-app montre le refus, avec le nom de la variable en cause.

La clé de chiffrement, à la ligne suivante, est nouvelle à chaque fois, car c’est justement ce que le test vérifie : un fichier chiffré doit s’ouvrir ici, sur une instance qui n’a jamais connu la clé de celle qui l’a produit.

Patrimoine net, opérations et prix de revient

Comparez avec l’instance réelle trois chiffres : le patrimoine net, le nombre d’opérations de votre compte le plus actif, et le PRU d’une ligne. Ils suffisent à repérer une restauration incomplète.