Sauvegarde et restauration #

Une sauvegarde utile doit permettre de restaurer un état cohérent du métier, des documents et des secrets structurants.

Éléments à protéger #

base PostgreSQL ;
données Redis si leur reprise est requise ;
volume isms_document_files ou bucket S3/MinIO ;
volume jwt_keys ;
configuration et secrets conservés hors Git ;
version exacte du code et des images déployées.

Les dépendances Composer et npm peuvent être reconstruites ; elles ne remplacent pas la sauvegarde des données.

Préparer une sauvegarde #

Définissez RPO, RTO, rétention, chiffrement, emplacement hors site et responsable. Vérifiez l’espace disponible et consignez versions de l’application et migrations.

Exemple logique PostgreSQL à adapter à votre environnement :

docker compose exec -T postgres pg_dump \
  -U "$POSTGRES_USER" -d "$POSTGRES_DB" -Fc > riskpilot.dump

Ne placez pas de mot de passe dans l’historique du terminal. Sauvegardez ensuite volumes documentaires et clés avec un outil qui préserve permissions et intégrité.

Vérifier #

Une réussite de commande ne suffit pas. Contrôlez taille, empreinte, chiffrement, lisibilité du catalogue et présence des documents. Copiez la sauvegarde hors du serveur principal selon votre politique.

Restaurer lors d’un exercice #

Créez une instance isolée et compatible.
Restaurez secrets et clés sans les exposer.
Restaurez PostgreSQL avant de rendre l’application accessible.
Restaurez documents et, si nécessaire, Redis.
Démarrez les services sans trafic utilisateur.
Appliquez uniquement les migrations compatibles avec la version restaurée.
Vérifiez /api/health, connexion, tenants, ACL, téléchargements et exports.
Consignez durée, écarts et actions d’amélioration.

Points de vigilance #

Une restauration avec un autre APP_SECRET peut rendre illisibles les secrets chiffrés. Des clés JWT différentes invalident les sessions, ce qui peut être souhaité après incident mais doit être anticipé. La base et les fichiers doivent provenir d’un point temporel cohérent.

Après sinistre #

Avant bascule, confirmez l’intégrité, changez les secrets suspectés, révoquez les sessions si nécessaire et documentez la décision. Ne testez jamais une restauration par-dessus l’unique instance de production.

Vérification isolée de restauration #

Après scripts/backup.sh, exécutez régulièrement ./scripts/restore-verify.sh /srv/backups/riskpilot/<horodatage>. La procédure démarre un PostgreSQL éphémère non exposé, importe le dump avec arrêt à la première erreur, vérifie la présence des tables, puis inspecte l’archive documentaire et le fichier Redis. Le conteneur de contrôle est supprimé dans tous les cas. Une sauvegarde ne doit être déclarée exploitable qu’après réussite de cette restauration réelle.