Exercices de reprise après sinistre

Un plan de reprise dit comment tout reconstruire ailleurs à partir de ce qui survit : le dépôt, le registre, le coffre et les sauvegardes. Le RTO est le temps que ça prend, le RPO la quantité de données qu'on peut perdre. Seul un exercice prouve les deux.

Comment ça marche

Garde le runbook sous forme de script dans le dépôt et exécute-le, tel quel, sur un environnement vide, à intervalle régulier. Il doit recréer ce qu'aucun fichier ne contient (les secrets depuis le coffre, les étiquettes de nœud, les réseaux), déployer la stack, attendre que les services soient prêts, restaurer les données depuis la dernière sauvegarde, et vérifier le résultat. Le temps que ça prend est le RTO que tu peux promettre ; l'âge de la sauvegarde est le RPO.

Ce qui casse

Un runbook que personne n'exécute s'éloigne de la plateforme : les noms de conteneurs changent, docker exec n'atteint pas une tâche sur un autre nœud, un secret externe ou une étiquette manque, un réseau refuse les conteneurs ponctuels, une restauration démarre avant que la base soit prête. Des sauvegardes jamais restaurées sont des espoirs, pas des sauvegardes.

Dans un terminal

printf '%s' "$DB_PASSWORD" | docker secret create shop_db_password -
docker node update --label-add pgdata=true worker-1
docker stack deploy -c stack.yaml shop
sleep 45
docker run --rm --network shop_backend -v ./backups:/backups postgres:16 \
  psql -h db -U shop -d shop -f /backups/shop-2026-10-15.sql

Regarde-le casser, puis répare-le

Écris le Dockerfile ou le fichier compose, tape les commandes docker, et regarde un serveur simulé les exécuter à travers redémarrages, mises à jour et trafic. Gratuit pour commencer.

Ouvrir le parcours Ouvrir le bac à sable