Tester une sauvegarde

Une sauvegarde que personne n’a restaurée est une hypothèse. La tester ne touche pas à votre instance, mais cela ne peut pas non plus être un second docker compose up : le fichier compose épingle son nom de projet, si bien qu’un second lancement depuis lui recrée la pile que vous faites tourner au lieu d’en dresser une copie à côté. Construisez l’image sous un nom à vous et lancez la paire à la main.

Dresser une copie à côté de votre instance

1. Un réseau et une base qui ne sont à personne d’autre.

   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 que rien d’autre n’occupe. Elle applique les migrations elle-même avant de servir, il n’y a donc pas d’étape de schéma séparée.

   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 n’importe quoi, importez votre fichier.

4. Démontez tout. Rien ici ne survit à la répétition, l’image comprise : c’est une copie de votre instance de près de 800 Mo, et c’est la pièce qui reste derrière sans qu’on la remarque, parce que rien ne la liste à côté 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 ce lancement

Les deux secrets de ce docker run sont engendrés plutôt que tapés, et celui d’accès tout particulièrement : le contrôle de démarrage refuse un JWT_ACCESS_SECRET de moins de 16 caractères, et un conteneur qu’il refuse sort aussitôt, après avoir appliqué les migrations. Plus rien n’écoute alors sur 8099, si bien que le navigateur qu’on vous a dit d’ouvrir ne répond rien du tout, et que le refus n’est que dans docker logs badlen-restore-app, où il nomme la variable.

La clé de chiffrement de la ligne du dessous est une clé neuve à chaque fois, et c’est le fond de la répétition plutôt qu’un raccourci : un fichier scellé s’ouvre ici, sur une instance qui n’a jamais vu la clé de celle qui l’a écrit.

Les trois chiffres

Comparez avec l’instance réelle : le patrimoine net, le nombre d’opérations de votre compte le plus chargé, et le PRU d’une ligne. Ces trois-là attrapent une restauration revenue incomplète.

Le dépôt fait la même chose sous assertion plutôt qu’à l’œil : apps/api/src/data-io/roundtrip.live.test.ts remplit un compte, l’exporte, fait supprimer son volume, restaure dans une base vide et compare les deux colonne par colonne. Son en-tête porte les commandes exactes. Il lui faut une base qu’il puisse détruire, il ne tourne donc que lorsque LIVE_DB_URL en nomme une ; sans cette variable il est sauté.