Files
Malio-ops/RebuildBdd

RebuildBdd

Orchestration de reconstruction de bases PostgreSQL à partir de dumps distants, avec préparation automatique des machines cibles, exécution non interactive et intégration web.


Objectif

Ce projet permet de :

  • préparer automatiquement une machine cible neuve ou partiellement configurée ;
  • déployer et mettre à jour les scripts sur la cible ;
  • préparer PostgreSQL localement sur la cible ;
  • récupérer le dernier dump disponible depuis un serveur de backup ;
  • restaurer une base PostgreSQL de manière non interactive ;
  • exposer un flux exploitable depuis une interface web via des retours JSON.

Fonctionnement global

Le flux standard est le suivant :

  1. Création ou mise à jour de la configuration dune cible
  2. Bootstrap initial de la cible
  3. Précheck de préparation
  4. Rebuild de la base

En pratique :

  • create-target-config.sh crée un fichier de configuration cible ;
  • bootstrap-target-host.sh prépare la machine cible ;
  • Checkup/check-target-readiness.sh valide lenvironnement ;
  • rebuild-bdd-core.sh exécute la restauration ;
  • run-rebuild-bdd.sh orchestre lensemble.

Architecture

Configuration

Le projet utilise deux niveaux de configuration :

1. Configuration globale

Fichier :

config/global.env

Contient les paramètres stables, par exemple :

  • dépôt Git des scripts ;
  • serveur de backup ;
  • clé SSH de lecture backup ;
  • valeurs par défaut PostgreSQL ;
  • options globales de bootstrap.

2. Configuration par cible

Fichiers :

config/targets/<nom_cible>.env

Chaque fichier cible contient :

  • accès SSH bootstrap ;
  • répertoires locaux de la cible ;
  • paramètres PostgreSQL ;
  • sous-répertoire backup associé ;
  • options spécifiques à la cible.

Arborescence recommandée

RebuildBdd/
├── bootstrap-target-host.sh
├── create-target-config.sh
├── run-rebuild-bdd.sh
├── rebuild-bdd-core.sh
├── config/
│   ├── global.env
│   └── targets/
│       ├── test.env
│       └── prod.env
└── Checkup/
    ├── check-postgresql.sh
    └── check-target-readiness.sh

Scripts

create-target-config.sh

Crée ou met à jour un fichier cible dans :

config/targets/<cible>.env

Usage :

./create-target-config.sh \
  --target test \
  --host 192.168.1.50 \
  --port 22 \
  --bootstrap-user backup_liot \
  --bootstrap-key /home/user/.ssh/id_ed25519_target_test \
  --runtime-user backup_liot \
  --repo-dir /home/backup_liot/RebuildBdd \
  --env-name RECETTE \
  --pguser backup_liot \
  --pgpassword secret \
  --dbs "sirh inventory ferme" \
  --backup-subdir bdd-recette

bootstrap-target-host.sh

Prépare une machine cible neuve ou quasi neuve :

  • connexion SSH bootstrap ;
  • installation des paquets minimum ;
  • création des dossiers ;
  • génération du .env cible ;
  • copie de la clé SSH backup ;
  • préparation de known_hosts ;
  • installation éventuelle dun sudoers.d minimal ;
  • synchronisation du dépôt ;
  • exécution de check-postgresql.sh.

Usage :

./bootstrap-target-host.sh --target test

Mode JSON :

./bootstrap-target-host.sh --target test --json-only

Checkup/check-postgresql.sh

Prépare PostgreSQL localement sur la cible :

  • installation si absent ;
  • démarrage du service ;
  • test de disponibilité ;
  • création du rôle PostgreSQL cible si nécessaire.

Ce script est prévu pour fonctionner en non interactif avec sudo -n.


Checkup/check-target-readiness.sh

Valide la préparation complète de la cible :

  • lecture du .env cible ;
  • vérification des chemins ;
  • permissions locales ;
  • permissions SSH ;
  • known_hosts ;
  • accès SSH au serveur de backup ;
  • exécution de check-postgresql.sh.

Mode JSON disponible pour usage web.


rebuild-bdd-core.sh

Script métier de reconstruction :

  • validation des paramètres ;
  • connexion au serveur de backup ;
  • récupération du dernier dump ;
  • récupération éventuelle du fichier des rôles ;
  • suppression/recréation de la base si autorisé ;
  • restauration des rôles ;
  • restauration du dump PostgreSQL ;
  • retour JSON final.

run-rebuild-bdd.sh

Script orchestrateur principal.

Il peut :

  • lancer le bootstrap si activé pour la cible ;
  • synchroniser le dépôt distant ;
  • lancer le précheck ;
  • exécuter le rebuild.

Usage :

./run-rebuild-bdd.sh \
  --target test \
  --db sirh \
  --overwrite yes \
  --restore-roles yes \
  --request-id web_001 \
  --non-interactive

Prérequis

Machine de lancement

Doit disposer de :

  • bash
  • ssh
  • scp
  • git
  • python3

Machine cible

Le bootstrap suppose :

  • accès SSH fonctionnel ;
  • utilisateur bootstrap existant ;
  • soit root, soit sudo -n déjà disponible pour le bootstrap initial.

Serveur de backup

Doit :

  • être joignable en SSH depuis la cible ;
  • accepter la clé de lecture backup ;
  • contenir les dumps dans larborescence attendue.

Structure des backups attendue

Exemple :

/home/malio-b/backups/
├── bdd-recette/
│   ├── sirh/
│   │   ├── sirh_2026-03-16_19-00-01.dump
│   ├── inventory/
│   ├── ferme/
│   └── user/
│       ├── user_2026-03-16_19-00-01.sql

Le script recherche :

  • le dernier dump dans :
<BACKUP_REMOTE_DIR>/<db>/<db>_*.dump
  • le dernier fichier rôles dans :
<BACKUP_REMOTE_DIR>/<REMOTE_ROLES_DIR_NAME>/user_*.sql

Configuration

1. Créer la configuration globale

Copier :

config/global.env.example

vers :

config/global.env

Renseigner ensuite :

  • dépôt Git ;
  • serveur de backup ;
  • clé SSH backup ;
  • defaults globaux.

2. Créer une cible

Deux possibilités.

A. À la main

Créer un fichier :

config/targets/test.env

à partir de :

config/targets/test.env.example

B. Via script

Utiliser :

./create-target-config.sh ...

Exécution locale

Bootstrap seul

./bootstrap-target-host.sh --target test

Rebuild complet

./run-rebuild-bdd.sh \
  --target test \
  --db sirh \
  --overwrite yes \
  --restore-roles yes \
  --non-interactive

Intégration web

Linterface web ne doit envoyer que les paramètres métier de lexécution :

{
  "target": "test",
  "db": "sirh",
  "overwrite": "yes",
  "restore_roles": "yes",
  "request_id": "web_20260317_001"
}

Le backend transforme cela en commande :

./run-rebuild-bdd.sh \
  --target test \
  --db sirh \
  --overwrite yes \
  --restore-roles yes \
  --request-id web_20260317_001 \
  --non-interactive

Important

Le web ne doit pas transmettre directement :

  • les clés SSH ;
  • les mots de passe PostgreSQL ;
  • les paramètres bas niveau de la cible ;
  • les chemins système sensibles.

Ces informations doivent être stockées dans la configuration serveur.


Ajouter une nouvelle machine depuis le web

Le flux recommandé est :

  1. créer ou mettre à jour config/targets/<cible>.env
  2. lancer bootstrap-target-host.sh --target <cible>
  3. lancer ensuite run-rebuild-bdd.sh --target <cible> ...

Le bouton web “Ajouter une machine” doit donc :

  • créer la configuration cible ;
  • déclencher le bootstrap ;
  • vérifier le retour ;
  • rendre ensuite la cible disponible pour les rebuilds.

Sorties JSON

Succès

Exemple :

{
  "status": "success",
  "message": "restauration terminée avec succès",
  "request_id": "web_001",
  "environment": "RECETTE",
  "database": "sirh",
  "dump_file": "/home/backup/backups/bdd-recette/sirh/sirh_2026-03-16_19-00-01.dump",
  "log_file": "/home/backup_liot/logs/rebuild_bdd/restore_recette_web_001_2026-03-17_09-10-00.log"
}

Erreur

Exemple :

{
  "status": "error",
  "message": "la base existe déjà et overwrite n'est pas autorisé",
  "request_id": "web_001",
  "environment": "RECETTE",
  "database": "sirh",
  "dump_file": "/home/backup/backups/bdd-recette/sirh/sirh_2026-03-16_19-00-01.dump",
  "log_file": "/home/backup_liot/logs/rebuild_bdd/restore_recette_web_001_2026-03-17_09-10-00.log"
}

Sécurité

Recommandations minimales

  • utiliser des clés SSH dédiées ;
  • limiter la clé backup à la lecture seule ;
  • restreindre les permissions des fichiers de config ;
  • exécuter les scripts avec un utilisateur dédié ;
  • ne pas exposer les secrets dans linterface web ;
  • valider strictement toutes les entrées côté backend.

sudoers

Le bootstrap peut installer un sudoers.d minimal pour lutilisateur runtime :

<user> ALL=(root) NOPASSWD: /usr/bin/apt, /usr/bin/apt-get, /usr/bin/systemctl
<user> ALL=(postgres) NOPASSWD: /usr/bin/psql

Adapter si dautres commandes doivent être autorisées.


Logs

Les logs de rebuild sont stockés dans :

TARGET_BACKUP_LOG_DIR

Exemple :

/home/backup_liot/logs/rebuild_bdd/

Le chemin du log est renvoyé dans le JSON final.


Limites connues

  • le bootstrap initial nécessite un accès SSH bootstrap valide ;
  • le bootstrap ne remplace pas une mauvaise architecture réseau ;
  • les secrets doivent être gérés proprement par la couche web/backend ;
  • des verrous dexécution peuvent être ajoutés si plusieurs rebuilds concurrents sont prévus.

Recommandations de validation

Avant mise en production, tester au minimum :

  1. bootstrap dune machine neuve ;
  2. rebuild complet dune base ;
  3. refus si la base existe et overwrite=no ;
  4. relance complète une seconde fois sur la même cible ;
  5. accès backup invalide ;
  6. PostgreSQL absent au départ ;
  7. sudo -n indisponible.

Commandes utiles

Créer une cible

./create-target-config.sh \
  --target test \
  --host 192.168.1.50 \
  --port 22 \
  --bootstrap-user backup_liot \
  --bootstrap-key /home/matteo/.ssh/id_ed25519_target_test \
  --runtime-user backup_liot \
  --repo-dir /home/backup_liot/RebuildBdd \
  --env-name RECETTE \
  --pguser backup_liot \
  --pgpassword secret \
  --dbs "sirh inventory ferme" \
  --backup-subdir bdd-recette

Bootstrap

./bootstrap-target-host.sh --target test

Rebuild

./run-rebuild-bdd.sh \
  --target test \
  --db sirh \
  --overwrite yes \
  --restore-roles yes \
  --non-interactive

État du projet

Le projet permet désormais une utilisation :

  • locale ;
  • automatisée ;
  • intégrée au web ;

avec préparation des cibles, exécution non interactive et retour JSON.