Documentation Index

Fetch the complete documentation index at: https://snakysec.mintlify.app/llms.txt

Use this file to discover all available pages before exploring further.

​

Test de restore E2E — runbook mensuel

​

Pourquoi ce test

• Spin up des cibles éphémères (Postgres + Vault containers, volumes tmpfs, jamais persistés)
• Restore le dernier backup de chaque asset depuis OVH (fallback Scaleway si OVH down)
• Smoke test : compte les tables Postgres, vérifie que le snapshot Vault est intact, sample les artifacts
• Mesure le RTO réel + le RPO du backup utilisé
• Écrit un rapport markdown horodaté dans docs/dr/test-restore-reports/YYYY-MM-DD.md

​

Cibles documentées

​

Quand le lancer

cd /chemin/vers/mssp-snakysec-multi-tenants
bash scripts/dr/restore/test-full-restore.sh

1. Host cron (Linux/macOS) : ajouter à /etc/cron.monthly/ :
   #!/bin/bash
   cd /opt/mssp/repo && bash scripts/dr/restore/test-full-restore.sh \
     >> /var/log/dr-test-restore.log 2>&1
   
2. Windows Task Scheduler : tâche déclenchée le 1er du mois 06:00, action = bash.exe scripts/dr/restore/test-full-restore.sh.
3. Ofelia : décommenter le job dans platform/docker/ofelia/config.ini après avoir ajouté un dr-test-runner image avec docker CLI + accès au docker.sock via socket-proxy.

​

Pré-requis

1. Le stack pré-prod doit tourner : make preprod. Au minimum mssp-vault et mssp-dr-runner doivent être up.
2. DR_BACKUPS_ENABLED=true au moins une fois dans le passé pour qu’il y ait des backups dans les buckets. Sinon le test détecte « no snapshot found » et exit en SKIP.
3. Les credentials DR sont peuplés dans mssp/dr/* (pas REPLACE_ME). Vérifier :
   docker exec -e VAULT_TOKEN=$(docker exec mssp-vault sh -c 'cat /vault/data/init-keys.json' | python -c "import sys,json;print(json.load(sys.stdin)['root_token'])") \
     -e VAULT_SKIP_VERIFY=true mssp-vault vault kv get mssp/dr
   
   Tous les fields doivent être set (pas REPLACE_ME, pas vides).
4. Les ports 5444 + 8244 doivent être libres sur l’host (utilisés par les containers éphémères du test).

​

Lecture d’un rapport

# DR test restore — 2026-05-02

**Run started:** 2026-05-02T08:30:00Z
**Run finished:** 2026-05-02T08:42:34Z
**Total RTO (wall-clock):** 754s
**Overall status:** **OK**

## Per-asset results

| Asset | Status | RPO (lag from latest backup) |
|---|---|---|
| Postgres (pgbackrest) | **OK** | 5h32min |
| Vault (raft snapshot)  | **OK** | 4h30min |
| Artifacts (restic)     | **OK** | — |

• Overall status = OK + RTO < 4h + RPO < 24h → Tout va bien, garde le rapport pour audit.
• Overall status = FAIL → Au moins un asset n’a pas pu être restoré → §Troubleshooting.
• Status = SKIP → Un asset n’avait pas de backup à restorer (typique en pré-prod si DR_BACKUPS_ENABLED a toujours été off).

​

Troubleshooting

​

”DR secret ‘mssp/dr/X’ is missing or REPLACE_ME”

cd platform && make vault-bootstrap-secrets
# Catégorie 8/8 — DR storage

​

“Ephemeral Postgres did not become ready within 60s”

docker ps --filter "publish=5444"   # devrait être vide
docker pull postgres:16-alpine     # warm le cache image

​

“Postgres restore appears empty (0 tables)”

• pgbackrest n’est pas pré-installé dans l’image postgres:16-alpine éphémère utilisée pour le test (le script tente apk add mais ça échoue offline). Mitigation V2 : utiliser l’image custom mssp-postgres:16-pgbackrest qui a déjà pgbackrest baked in.
• Le cipher pass diverge entre Vault et le backup (rotation accidentelle = backup illisible). Crisis : tu ne peux pas récupérer les backups antérieurs à la rotation.

cat /tmp/dr-test-<run-id>/pg-restore.log

​

“No restic snapshot found for vault”

docker exec mssp-dr-runner sh -c '
  AWS_ACCESS_KEY_ID=$(vault kv get -field=ovh_s3_access_key mssp/dr) \
  AWS_SECRET_ACCESS_KEY=$(vault kv get -field=ovh_s3_secret_key mssp/dr) \
  aws --endpoint-url=https://s3.gra.io.cloud.ovh.net \
    s3 ls s3://mssp-backup-ovh/vault/ | tail
'

docker exec mssp-cron ofelia exec --config=/etc/ofelia/config.ini --job=vault-snapshot

​

“RTO > 6h sur Postgres”

• Le bucket OVH est congestionné ou la liaison Internet de l’host est limitée.
• Trop de WAL à rejouer depuis le full (post-Day 80 le WAL accumulé peut être volumineux).
• Le test tourne pendant que d’autres backups poussent en parallèle.

​

Sentry monitor dr-test-restore rouge

1. Lire le rapport markdown du jour
2. Reproduire en local : bash scripts/dr/restore/test-full-restore.sh à la main
3. Si rouge persistant > 2 mois consécutifs → escalation : la promesse de DR est cassée, faut reconstruire la chaîne de backup (full sync + verify).

​

Rétention des rapports

cd docs/dr/test-restore-reports
{
  echo "# Index des rapports test restore"
  echo ""
  ls -1 *.md | grep -v "^index.md$" | sort -r | head -36 | while read f; do
    date=$(basename "$f" .md)
    overall=$(grep -m1 "Overall status" "$f" | sed -E 's/.*\*\*([A-Z]+)\*\*.*/\1/')
    rto=$(grep -m1 "Total RTO" "$f" | sed -E 's/.*: ([0-9]+s).*/\1/')
    echo "- [${date}](${f}) — ${overall} (RTO ${rto})"
  done
} > index.md

​

Éviter les pièges

• Ne jamais lancer le test pendant un backup réel (collision OVH/Scaleway list operations). Le test est volontairement programmé après dr-verify (06:30 UTC) pour éviter le créneau full backup (02:00).
• Ne jamais ALTER les buckets OVH/Scaleway depuis le test. Read-only seulement. Si le test fait écrire = bug à fixer immédiatement.
• Le test ne valide PAS la chaîne de Shamir keyholders Vault — c’est un autre runbook (docs/dr/01-keyholders.md) avec un test annuel manuel séparé.

​

Décisions historiques