Sauvegardes et restauration

Quoi sauvegarder, comment chiffrer et répliquer les dumps, comment restaurer et le tester, et comment fonctionne le rollback avec des migrations forward-only.

PostgreSQL porte des données critiques et non régénérables : comptes, identifiants argon2id, secrets MFA chiffrés, clés privées OIDC chiffrées et le journal d'audit immuable. L'immuabilité de l'audit (un trigger bloque UPDATE et DELETE) ne protège pas d'une perte de disque : les sauvegardes sont indispensables.

Où vit l'état

PostgreSQL est l'état. Tout ce qui est durable y vit. C'est le seul composant dont la perte est irrécupérable sans sauvegarde.
Redis est volatile et reconstructible. Il tourne délibérément sans persistance : un redémarrage vide les sessions actives (les utilisateurs se reconnectent) mais aucune donnée durable n'est touchée.
Protégez aussi : votre .env.prod (dans un coffre à secrets, car il contient ENCRYPTION_KEY), et le volume MinIO si vous l'utilisez pour les logos de tenant (re-téléversables, mais une sauvegarde évite la corvée). Les certificats Caddy n'ont pas besoin de sauvegarde : ACME les réémet.

Sauvegarder PostgreSQL

Le dépôt fournit scripts/backup.sh (un pg_dump au format custom, avec rétention) :

DATABASE_URL=postgres://obexal:$DB_PASSWORD@db-host:5432/obexal \
BACKUP_DIR=/var/backups/obexal RETENTION_DAYS=14 \
  ./scripts/backup.sh

Lancez-le quotidiennement par cron, et toujours avant une migration ou une rotation de clé :

0 3 * * *  DATABASE_URL=... BACKUP_DIR=/var/backups/obexal /opt/obexal/scripts/backup.sh >> /var/log/obexal/backup.log 2>&1

Les dumps sont écrits en chmod 600 : ils contiennent des données personnelles et des secrets chiffrés. Chiffrez-les au repos et répliquez-les vers un bucket objet UE distinct. Sur un PostgreSQL managé UE, activez de plus le point-in-time recovery (archivage des WAL) en complément des dumps logiques : c'est la protection de référence en production.

La clé de chiffrement fait partie de la sauvegarde

Une restauration de base n'a de valeur que si la clé de chiffrement correspondante est disponible : ENCRYPTION_KEY (et toute ENCRYPTION_KEY_OLD encore référencée) déchiffre les secrets TOTP et les clés privées OIDC contenus dans le dump.

Danger

Conservez ENCRYPTION_KEY dans un coffre à secrets, séparément des dumps. Un dump et sa clé stockés ensemble annulent le chiffrement ; un dump sans sa clé est illisible.

Si vous restaurez un dump antérieur à une rotation de clé, fournissez la clé de cette époque via ENCRYPTION_KEY_OLD, puis lancez reencrypt-secrets.

Restaurer

scripts/restore.sh est destructif et exige une confirmation explicite :

CONFIRM=yes DATABASE_URL=postgres://obexal:$DB_PASSWORD@target-host:5432/obexal \
  ./scripts/restore.sh /var/backups/obexal/obexal-20260701T030000Z.dump

Tester vos restaurations

Une sauvegarde non testée n'existe pas. Planifiez un exercice de restauration (le trimestre est une bonne cadence), sur une base jetable :

Restaurer le dernier dump.
Démarrer l'auth-service contre cette base.
Vérifier : une connexion par mot de passe, /.well-known/jwks.json (clés de signature présentes), une complétion MFA, et /v1/auth/me.
Consigner le temps écoulé : c'est votre RTO réel.

Rollback applicatif

Les migrations sont forward-only : il n'y a pas de migrations descendantes, par conception. Elles sont additives et compatibles avec la version N-1, donc dans la plupart des cas un rollback consiste simplement à redéployer l'image applicative précédente, sans toucher à la base. Ce n'est que lorsqu'une migration a introduit un changement incompatible que vous restaurez le dump pris juste avant le déploiement : c'est pourquoi sauvegarder avant chaque mise à jour n'est pas négociable.

RGPD et rétention

La suppression d'un compte purge les données vivantes en cascade, mais les sauvegardes restent soumises à leur fenêtre de rétention (RETENTION_DAYS, 14 jours par défaut). Documentez cette durée dans votre registre de traitement et votre politique de conservation, et réduisez-la si vos exigences de minimisation l'imposent. Voir RGPD.