1. Ce Qui Est Sauvegardé (et Comment)

Cible (APP=) Container Type Méthode

clarajob-ddl

clarajob-ddl

PostgreSQL

pg_dump --clean --if-exists → fichier .sql

clarajob-mongo

clarajob-mongo

MongoDB

mongodump --archive → fichier .archive

marketisia-sa

marketisia-ddl

PostgreSQL

pg_dump --clean --if-exists → fichier .sql

auth-server-db

auth_server_db

PostgreSQL (Keycloak)

pg_dump --clean --if-exists → fichier .sql

all

les 4 ci-dessus

—

enchaîne les 4 backups

(MinIO — restore uniquement)

minio-service

Object storage

backup continu par le sidecar minio-backup (mc mirror) vers clarajob_sa/backups/minio/

Emplacement des dumps (sur le serveur) :

/home/admin/app/sever-admin/db-config/dump/<db_service>/
    <db_service>-YYYY-MM-DD_HHMMSS.sql        (PostgreSQL)
    <db_service>-YYYY-MM-DD_HHMMSS.archive    (MongoDB)

/home/admin/app/sever-admin/db-config/dump_description/<db_service>/
    <fichier_dump>_<description>.txt          (description horodatée)

Les descriptions possibles : auto-backup (backup manuel/cron) et pre-deploy (backup automatique avant déploiement).

Réalité du système actuel :

  • Les dumps ne sont pas compressés (.sql / .archive bruts).

  • Il n’y a pas de rotation/purge automatique — les dumps s’accumulent tant qu’on ne les supprime pas manuellement.

  • Il n’y a pas de copie hors-serveur automatisée des dumps DB (les dumps restent sur le disque du serveur). Le seul backup « continu » est celui de MinIO via son sidecar.

2. Backup Manuel

make backup APP=clarajob-ddl        # PostgreSQL ClaraJob
make backup APP=clarajob-mongo      # MongoDB ClaraJob
make backup APP=marketisia-sa       # PostgreSQL PredictX
make backup APP=auth-server-db      # PostgreSQL Keycloak
make backup APP=all                 # tout
make backup APP=clarajob-ddl ENV=local    # sur ta machine locale

Garanties intégrées au rôle backup :

  1. Échec explicite si les credentials (vault) sont vides

  2. Échec si le container DB ne tourne pas

  3. Échec si le dump produit est vide ou absent — un backup silencieusement vide est impossible

  4. Confirmation finale avec chemin + taille en octets

Sortie type :

TASK [backup : Afficher confirmation]
ok: [vps-main] => {
    "msg": "Backup créé : /home/admin/app/sever-admin/db-config/dump/clarajob-ddl/clarajob-ddl-2026-07-26_143012.sql (128456789 octets)"
}

3. Backups Automatiques (Cron)

Installés une seule fois par make setup-cron. Ils tournent sur le serveur lui-même (Ansible installé sur le serveur, vault dans /opt/.vault_password, exécution root) :

Cron Heure Cible

backup-marketisia-sa-daily

03:00

PostgreSQL marketisia-ddl

backup-clarajob-ddl-daily

04:00

PostgreSQL clarajob-ddl

backup-clarajob-mongo-daily

05:00

MongoDB clarajob-mongo

  • Logs : /var/log/ansible-backup.log

  • Vérifier les crons : ssh admin@18.158.207.98 puis sudo crontab -l

  • ⚠️ auth-server-db n’a pas de cron — backup manuel ou pre-deploy uniquement

Backups pre-deploy automatiques (en plus des crons) — déclenchés par make deploy si le container tourne :

make deploy APP= Backup automatique de

clarajob-sa

clarajob-ddl + clarajob-mongo

clarajob-ddl

clarajob-ddl

clarajob-mongo

clarajob-mongo

marketisia-sa

marketisia-ddl

keycloak ou auth-server-db

auth_server_db

4. Backup MinIO (Object Storage)

MinIO n’est pas sauvegardé par make backup mais par un sidecar dédié défini dans le compose de clarajob_sa : le container minio-backup exécute mc mirror et copie les données vers /home/admin/app/clarajob_sa/backups/minio/<horodatage>/.

Pour le relancer : make deploy APP=minio-backup.

5. Restore — Bases de Données

APP et DUMP obligatoires. Le fichier DUMP doit exister dans db-config/dump/<db_service>/ sur la machine cible.

# 1. Lister les dumps disponibles
ssh -i ~/.ssh/serverAdminSSHKeypair.pem admin@18.158.207.98 \
  "ls -lht /home/admin/app/sever-admin/db-config/dump/clarajob-ddl/ | head"

# 2. Restaurer (le nom de fichier seul suffit, pas le chemin complet)
make restore APP=clarajob-ddl   DUMP=clarajob-ddl-2026-07-26_040000.sql
make restore APP=clarajob-mongo DUMP=clarajob-mongo-2026-07-26_050000.archive
make restore APP=marketisia-sa  DUMP=marketisia-ddl-2026-07-26_030000.sql
make restore APP=auth-server-db DUMP=auth_server_db-2026-07-26_060000.sql

Comportement exact du rôle restore :

  • Vérifie que le container tourne, et que le dump existe (échec explicite sinon)

  • PostgreSQL : psql -U <user> -d <db> < dump — le dump ayant été créé avec --clean --if-exists, les objets existants sont drop puis recréés

  • MongoDB : mongorestore --drop --archive < dump — --drop écrase les collections existantes

  • Il n’y a pas d’arrêt des applications pendant le restore : pour une restauration propre en production, arrêter d’abord l’API concernée :

# Exemple restauration propre de ClaraJob :
ssh admin@18.158.207.98 "cd /home/admin/app/clarajob_sa && docker compose stop clarajob-front-api"
make restore APP=clarajob-ddl DUMP=clarajob-ddl-2026-07-26_040000.sql
make deploy APP=clarajob-front-api      # relance l'API

Le restore est destructif (drop des objets/collections). En cas de doute, faire un make backup APP=<cible> juste avant le restore pour capturer l’état courant.

6. Restore — MinIO

# Restaurer depuis le backup le plus récent
make restore APP=minio-service DUMP=latest

# Restaurer depuis un répertoire de backup précis
make restore APP=minio-service DUMP=/home/admin/app/clarajob_sa/backups/minio/2026-04-05_0600

Comportement du rôle restore_minio :

  1. DUMP=latest → sélectionne le répertoire le plus récent dans backups/minio/

  2. Arrête minio-service

  3. docker run minio/mc : mc mirror /backups/ /data/ vers le volume clarajob_sa_minio_data

  4. Redémarre minio-service, pause 10s, vérifie le container — rollback + message si échec

7. Scénario Complet : Récupération Après Incident

# Contexte : l'API ClaraJob renvoie des erreurs après une mauvaise migration.

# 1. Identifier le dernier bon dump (le pre-deploy créé juste avant le déploiement fautif)
ssh -i ~/.ssh/serverAdminSSHKeypair.pem admin@18.158.207.98
ls -lht /home/admin/app/sever-admin/db-config/dump/clarajob-ddl/ | head -5
cat /home/admin/app/sever-admin/db-config/dump_description/clarajob-ddl/*pre-deploy* | tail -3
exit

# 2. Arrêter l'API pour éviter les écritures pendant le restore
ssh admin@18.158.207.98 "cd /home/admin/app/clarajob_sa && docker compose stop clarajob-front-api"

# 3. Sauvegarder l'état corrompu (au cas où)
make backup APP=clarajob-ddl

# 4. Restaurer le dump pre-deploy
make restore APP=clarajob-ddl DUMP=clarajob-ddl-2026-07-26_141502.sql

# 5. Redéployer l'API en version stable
make deploy APP=clarajob-front-api TAG=v1.1.9

# 6. Vérifier
ssh admin@18.158.207.98 "docker logs clarajob-front-api --tail 50"
# + contrôle visuel dans Dozzle (port 9999)

8. Vérifications et Maintenance

# Santé des backups cron (sur le serveur)
tail -50 /var/log/ansible-backup.log        # dernières exécutions
sudo crontab -l                              # les 3 crons présents ?

# Espace disque occupé par les dumps
du -sh /home/admin/app/sever-admin/db-config/dump/*

# Nettoyage manuel des vieux dumps (PAS automatique — à faire régulièrement)
# Exemple : supprimer les dumps de plus de 30 jours
find /home/admin/app/sever-admin/db-config/dump/ -name "*.sql" -mtime +30 -delete
find /home/admin/app/sever-admin/db-config/dump/ -name "*.archive" -mtime +30 -delete

Bonnes pratiques recommandées (au-delà de l’existant) :

  1. Tester un restore sur ENV=local régulièrement — un backup non testé n’est pas un backup

  2. Copier périodiquement les dumps hors du serveur (scp/rclone vers un stockage externe) — actuellement les dumps DB ne quittent pas le serveur

  3. Surveiller /var/log/ansible-backup.log — un cron qui échoue en silence est le pire scénario

  4. Nettoyer les vieux dumps pour ne pas saturer le disque

9. Erreurs Courantes

Message Solution

Le fichier dump '…​' est introuvable

DUMP doit être le nom exact du fichier (avec extension), présent dans db-config/dump/<service>/. Lister avec ls sur le serveur.

Le dump …​ est vide ou n’a pas été créé

Credentials DB incorrects dans vault.yml, ou container DB en mauvais état. Tester : docker exec clarajob-ddl pg_isready

Les variables db_service…​ sont obligatoires

vault.yml ne se déchiffre pas → vérifier ~/.vault_sever_admin

Restore PostgreSQL échoue avec « database is being accessed »

Arrêter d’abord l’API qui tient des connexions (docker compose stop <api>), relancer le restore, redémarrer l’API

Cron ne produit pas de dump

Vérifier /opt/.vault_password existe sur le serveur et tail /var/log/ansible-backup.log

10. Prochaines Étapes