Aller au contenu principal

Restauration

Avant toute restauration
  1. Sauvegarder l'état actuel (même abîmé) : on peut avoir besoin d'y revenir.
  2. Prévenir les utilisateurs : l'application est indisponible pendant l'opération.
  3. Restaurer d'abord en préproduction quand c'est possible, pour valider le fichier.

Base de données depuis un dump​

cd ~/pch-sig
F=docker-compose.prod.yml                  # ou docker-compose.preprod.yml
PG=$(docker ps --filter name=pch_postgres --format '{{.Names}}' | grep -v exporter | head -1)

# 1. Arrêter le backend (plus aucune écriture)
docker compose -f $F stop backend

# 2. Recréer une base vide
docker exec "$PG" sh -c 'dropdb -U "$POSTGRES_USER" --if-exists "$POSTGRES_DB" && createdb -U "$POSTGRES_USER" "$POSTGRES_DB"'
docker exec "$PG" sh -c 'psql -U "$POSTGRES_USER" -d "$POSTGRES_DB" -c "CREATE EXTENSION IF NOT EXISTS postgis; CREATE EXTENSION IF NOT EXISTS unaccent;"'

# 3. Charger le dump
gunzip -c ~/backups/pch_sig_AAAAMMJJ_HHMMSS.sql.gz | docker exec -i "$PG" sh -c 'psql -U "$POSTGRES_USER" -d "$POSTGRES_DB"'

# 4. Redémarrer le backend (il joue les migrations manquantes et remet les droits)
docker compose -f $F up -d --no-deps backend
docker exec pch_backend curl -s http://127.0.0.1:8000/api/health

Après restauration :

  • Réindexer la base documentaire de l'assistant : docker exec -u www-data pch_backend php bin/console app:assistant:indexer --sans-vecteurs.
  • En production, prévenir l'équipe de l'esclave de secours : la réplication doit être réinitialisée à partir de la nouvelle base.

Base de production depuis l'esclave de secours​

En cas de perte du serveur de production, la base la plus récente est la réplique de axone-dr (ou son dernier instantané restic). Cette opération est menée avec l'équipe qui administre l'esclave : promotion de la réplique ou export d'un dump, puis restauration sur le nouveau serveur comme ci-dessus.

Fichiers téléversés​

docker run --rm -v pch-sig_backend_uploads:/data -v ~/backups:/in alpine \
  sh -c 'rm -rf /data/* && tar -xzf /in/uploads_AAAAMMJJ.tar.gz -C /data'
docker compose -f $F up -d --no-deps backend      # remet les droits à www-data

GitLab (préproduction)​

La restauration exige les deux fichiers du même jour : l'archive applicative et la configuration (gitlab-secrets.json). Sans ce dernier, les jetons, la double authentification et les variables CI sont perdus.

cd ~/gitlab
tar -xzf ~/backups/gitlab/gitlab-config_AAAAMMJJ_HHMMSS.tar.gz -C /tmp       # puis recopier dans le volume /etc/gitlab
docker cp ~/backups/gitlab/<horodatage>_gitlab_backup.tar gitlab:/var/opt/gitlab/backups/
docker exec gitlab gitlab-ctl stop puma && docker exec gitlab gitlab-ctl stop sidekiq
docker exec -it gitlab gitlab-backup restore BACKUP=<horodatage>
docker compose -f docker-compose.yml restart

Procédure complète et précautions dans docs/GITLAB_SERVEUR.md du dépôt.

Tester les sauvegardes​

Au moins une fois par trimestre : restaurer le dernier dump de production sur la préproduction et vérifier qu'on se connecte et que les écrans principaux s'affichent. Une sauvegarde jamais restaurée n'est pas une sauvegarde.