Skip to main content

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.

​
Activer les backups DR en pré-prod (stack Docker locale)

​
Topologie

ÉlémentPré-prod actuelleProd cible (Q3+)
Stack DockerMac/Windows du founderVPS dédié
Vaultpersistent file storage (équivalent prod)Shamir 5/3, bare-metal
Postgresdocker volume postgres-datadocker volume sur VPS
Backups vers OVH/Scalewaydormants par défautactifs H24

​
Pourquoi les backups sont dormants par défaut en pré-prod

docker compose lance mssp-dr-runner + mssp-cron (Ofelia) dès make preprod, mais chaque script de backup commence par : 
dr_backups_enabled || exit 0
Cette fonction (cf. scripts/dr/lib/common.sh) lit DR_BACKUPS_ENABLED depuis l’env. Si non set ou false → le script log « DR backups disabled » et exit 0. Ofelia voit succès, pas d’alerte Sentry. Conséquence : tu peux booter la stack tout le temps, faire du dev, sans spammer OVH/Scaleway avec des données de dev.

​
Activer les backups (test ou prod réelle)

​
1. Renseigner les secrets DR dans Vault

Le mssp/dr path est seedé au first-init Vault avec pgbackrest_repo_cipher_pass et restic_password auto-générés (32 bytes hex), mais les keys S3 sont en REPLACE_ME. Walkthrough interactif : 
cd platform
make vault-bootstrap-secrets
# Catégorie 8/8 — DR storage
# Renseigner :
#   • OVH S3 access key + secret key
#   • Scaleway S3 access key + secret key
# Les ciphers sont déjà auto-générés, laisse vide pour conserver.
Les credentials S3 viennent de :
  • OVH : Public Cloud → Object Storage → Users → Create S3 credentials
  • Scaleway : Identity Access Management → API keys → Create API key with S3 access

​
2. Provisionner les buckets (Object Lock + Versioning)

docker exec -it mssp-dr-runner /dr/setup/bootstrap-buckets.sh
Si premier lancement : crée mssp-backup-ovh + mssp-backup-scw avec Object Lock COMPLIANCE 90j (cf. 04-object-lock-procedures.md).

​
3. Activer le kill-switch

echo "DR_BACKUPS_ENABLED=true" >> platform/.env
docker restart mssp-dr-runner mssp-cron

​
4. Tester un backup manuellement (sans attendre le cron)

# Force un snapshot Vault immédiat
docker exec mssp-cron ofelia exec --config=/etc/ofelia/config.ini --job=vault-snapshot

# Vérifier dans dr-runner les logs du run
docker logs mssp-dr-runner | tail -30 | grep -E "vault-snapshot|restic|pushed"

# Vérifier que le snapshot est bien arrivé sur OVH
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 -3
'

​
Contraintes opérateur

​
Ton PC doit être allumé pendant les fenêtres cron

JobSchedule UTCSchedule ParisAsset
pgbackrest fullDim 02:00Dim 04:00 (été) / 03:00 (hiver)Postgres
pgbackrest diffLun-Sam 03:00Lun-Sam 05:00 (été) / 04:00 (hiver)Postgres
vault-snapshotQuotidien 04:0006:00 / 05:00Vault
artifacts-resticQuotidien 05:0007:00 / 06:00artifacts/
dns-zone-export1er du mois 06:0008:00 / 07:00DNS OVH
dr-verifyQuotidien 06:3008:30 / 07:30integrity check
Si ton PC est éteint à 04:00, ce backup-là saute. Le cron ne rattrape pas. Les jours suivants reprennent normalement. Pour limiter le risque de gap RPO en pré-prod :
  • Met ton PC en mode “wake on schedule” via Windows Task Scheduler ou macOS Energy Saver schedule (option “Start up at…”).
  • OU laisse l’app + Docker tourner H24 (consommation : ~30W idle, ~7€/mois si tu fermes l’écran).
  • OU bascule sur prod VPS dès qu’il est dispo (cible Q3 2026).

​
Le port mssp-vault doit être joignable depuis mssp-dr-runner

Vérifié par défaut grâce à mssp-net (network bridge interne). Si le réseau Docker est cassé, vérifier : 
docker exec mssp-dr-runner curl -ks https://mssp-vault:8200/v1/sys/health
# → JSON {"sealed":false,...}

​
Désactiver (mode dev sans push)

sed -i 's/DR_BACKUPS_ENABLED=true/DR_BACKUPS_ENABLED=false/' platform/.env
docker restart mssp-dr-runner mssp-cron

# Vérifier que le kill-switch fonctionne
docker exec mssp-cron ofelia exec --config=/etc/ofelia/config.ini --job=vault-snapshot
docker logs mssp-dr-runner | tail -3 | grep "DR backups disabled"
# → "DR backups disabled via DR_BACKUPS_ENABLED='false' — skipping."

​
Monitorer la santé des backups

​
Logs Ofelia

# Voir tous les jobs déclenchés (success + fail)
docker logs mssp-cron | grep "job"

# Voir les jobs qui ont fail
docker logs mssp-cron | grep -i "fail\|error"

​
Sentry monitor check-ins

Chaque script appelle sentry_check_in <slug> <status> au début et à la fin. Dans Sentry → Insights → Crons :
  • dr-postgres-full : doit passer chaque dimanche
  • dr-postgres-diff : doit passer lun-sam
  • dr-vault-snapshot : doit passer chaque jour
  • dr-artifacts-backup : idem
  • dr-dns-zone-export : doit passer le 1er du mois
Si un monitor passe en rouge → consulter docker logs mssp-dr-runner | grep <job>.

​
Vérification d’intégrité post-backup

dr-verify.sh tourne quotidien à 06:30 UTC. Il :
  • Compte les snapshots OVH + Scaleway
  • Vérifie que le dernier est < 30h
  • Confirme que les checksums restic sont OK
  • Sentry monitor dr-verify → vert si OK
Si rouge persistant → investigation manuelle : 
docker exec -it mssp-dr-runner /dr/verify/dr-verify.sh
# Output verbose stagiaire

​
Désactivation totale (pas de cron du tout)

Sortir compose/dr.yml du stack pré-prod : 
# Arrêter les 2 containers
docker rm -f mssp-cron mssp-dr-runner

# Édit Makefile : retirer `-f compose/dr.yml` de COMPOSE_PREPROD
# Puis relancer le stack
cd platform && make preprod
Mais c’est rarement nécessaire — le kill-switch DR_BACKUPS_ENABLED=false couvre 99% des cas en gardant les containers prêts.

​
Migration vers prod VPS (futur Q3+)

Quand un VPS sera engagé :
  1. Provisionner Postgres + Vault + dr-runner + Ofelia sur le VPS via make prod
  2. DR_BACKUPS_ENABLED=true dans le .env du VPS
  3. Décommissionner les jobs locaux (kill-switch off en local)
  4. Surveiller les Sentry monitors pendant 30j pour s’assurer que les jobs partent bien depuis le VPS
Cf. pipelines/platform-deploy.yml — le job platform:deploy a été commenté en attendant. Décommenter + configurer 4 vars CI (VPS_SSH_KEY, VPS_HOST, VPS_USER, VPS_DEPLOY_DIR).