DPE — Restauration des BDD de prod en préprod

Un CronJob par base récupère le dernier backup de production dans un bucket S3 et le restaure dans la base de préproduction correspondante. Les dumps faisant plusieurs centaines de Go, ils sont streamés directement de S3 vers la base, sans passer par le disque.

Le détail des paramètres est documenté dans les commentaires du chart (values.yaml) et en tête du script de l'image.

Où se trouve quoi

Élément	Emplacement
Image Docker	repo tooling-infra, https://gitlab.ademe.fr/ademe-group/infrastructure/tooling-infra, dossier build/k8s-pgsql-restore-dpe (script resources/perform-pgsql-restore.sh)
Build de l'image	job CI manuel build-pgsql-restore-dpe (branche main) → rg.fr-par.scw.cloud/namespace-scw-service/pgsql-restore-dpe:latest
Chart Helm	dpe-pgsql-restore-chart, https://gitlab.ademe.fr/ademe-group/infrastructure/charts/dpe-pgsql-restore-chart (inspiré de pgsql-backup-chart)
Credentials S3	Vault ademe/cluster-service/scaleway_credentials, comme le chart de backup
Mot de passe des bases cibles	Vault ademe/apps/dpe/preprod, propriété databases[].passwordProperty

Fonctionnement

Pour chaque entrée de databases dans les values du chart :

1. Recherche du backup le plus récent (date de modification S3) dans backup.bucket / backup.path dont le nom matche backupFileRegex
2. Détection du format du dump (custom, tar, SQL, gzippé ou non) et de sa version sur ses premiers octets
3. Coupure des sessions de l'utilisateur cible sur la base
4. Suppression des objets appartenant à l'utilisateur cible dans la base (les autres bases de l'instance ne sont pas touchées)
5. Restauration en streaming : rclone cat → (gunzip) → pg_restore --no-owner --no-privileges (ou psql pour un dump SQL)
6. Exécution des scripts SQL postRestoreScripts (anonymisation…), puis ANALYZE pour recalculer les statistiques du planificateur

Points d'attention

La base cible est vidée avant la restauration

Pendant la restauration, la base de préprod est vide puis partiellement remplie. En cas d'échec, elle reste dans cet état jusqu'au prochain run réussi (backoffLimit: 0, pas de relance automatique).

• Les CronJobs sont suspendus par défaut (suspend: true). Le rendu du chart échoue si short_env vaut prod ou si une base cible commence par prod-.
• La restauration est mono-thread (pg_restore -j nécessite un fichier) : compter plusieurs heures pour les grosses bases. La progression du streaming est loggée toutes les 5 minutes ; la création des index en fin de restauration n'apparaît pas dans ces logs (suivre pg_stat_progress_create_index).
• Le warning pg_restore completed before the end of the stream est normal : pg_restore a terminé sans lire la fin du fichier.
• Préférer les dumps au format custom : avec un dump SQL, psql exécuterait les éventuels \connect qu'il contient (dumps faits avec pg_dump -C ou pg_dumpall) et changerait de base.