Skip to main content

Backup & restore

Strategie de sauvegarde de la base d'application Auralith (la DB qui stocke les users, projects, audit). Distinct des DB introspectees (qui restent a votre charge).

Quand l'utiliser​

Avant tout deploiement majeur, avant une migration Alembic, et tout le temps en prod (cron quotidien minimum).

Workflow rapide​

Backup automatise (recommande)​

  1. Sur le host Postgres qui heberge la base Auralith, configurer pg_dump en cron.
  2. Pousser le dump vers S3 / GCS / Backblaze avec retention 30 jours minimum.
  3. Verifier le checksum chaque nuit.
pg_dump --format=custom --no-owner --no-acl auralith \
  > /backups/auralith-$(date +%Y%m%d).dump
aws s3 cp /backups/auralith-$(date +%Y%m%d).dump \
  s3://my-bucket/auralith/

Backup managed (RDS / Cloud SQL)​

Activer les snapshots automatiques cote provider. Retention >= 7 jours. Tester un restore tous les trimestres.

Restore​

# 1. Stopper Auralith
docker compose down

# 2. Restaurer la base
pg_restore --clean --if-exists --no-owner -d auralith \
  /backups/auralith-20260424.dump

# 3. Redemarrer
docker compose up -d

# 4. Verifier la sante
curl https://app.example.com/health

Concepts cles​

  • App DB : ce qu'Auralith persiste (users, projects, patches, audit). Une centaine de Mo typique pour 50 users actifs.
  • Volumes Docker : si vous heberger Postgres en container, le volume postgres_data doit etre dans la sauvegarde infra.
  • Secrets : la SECRET_KEY est utilisee pour chiffrer les credentials de connexion DB. Sauvegardez-la separement — sans elle, le restore est inutile.

Pieges courants​

  • Restore avec une SECRET_KEY differente : tous les credentials chiffres sont illisibles. Vous perdez les connexions, faut tout reconfigurer.
  • Pas de test de restore : un backup non teste = pas de backup. Faire un restore complet en staging trimestriel.
  • Migrations Alembic en cours pendant backup : pg_dump pendant un alembic upgrade peut produire un dump incoherent. Verrouiller deploys pendant le backup window.

Voir aussi​