10 KiB
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 :
- Création ou mise à jour de la configuration d’une cible
- Bootstrap initial de la cible
- Précheck de préparation
- Rebuild de la base
En pratique :
create-target-config.shcrée un fichier de configuration cible ;bootstrap-target-host.shprépare la machine cible ;Checkup/check-target-readiness.shvalide l’environnement ;rebuild-bdd-core.shexécute la restauration ;run-rebuild-bdd.shorchestre l’ensemble.
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
.envcible ; - copie de la clé SSH backup ;
- préparation de
known_hosts; - installation éventuelle d’un
sudoers.dminimal ; - 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
.envcible ; - 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 :
bashsshscpgitpython3
Machine cible
Le bootstrap suppose :
- accès SSH fonctionnel ;
- utilisateur bootstrap existant ;
- soit
root, soitsudo -ndé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 l’arborescence 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
L’interface web ne doit envoyer que les paramètres métier de l’exé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 :
- créer ou mettre à jour
config/targets/<cible>.env - lancer
bootstrap-target-host.sh --target <cible> - 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 l’interface web ;
- valider strictement toutes les entrées côté backend.
sudoers
Le bootstrap peut installer un sudoers.d minimal pour l’utilisateur runtime :
<user> ALL=(root) NOPASSWD: /usr/bin/apt, /usr/bin/apt-get, /usr/bin/systemctl
<user> ALL=(postgres) NOPASSWD: /usr/bin/psql
Adapter si d’autres 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 d’exécution peuvent être ajoutés si plusieurs rebuilds concurrents sont prévus.
Recommandations de validation
Avant mise en production, tester au minimum :
- bootstrap d’une machine neuve ;
- rebuild complet d’une base ;
- refus si la base existe et
overwrite=no; - relance complète une seconde fois sur la même cible ;
- accès backup invalide ;
- PostgreSQL absent au départ ;
sudo -nindisponible.
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.