Sauvegarde & Restauration

Ce qui conserve vos données dans une installation Conzent OCI auto-hébergée, comment les sauvegarder selon un calendrier, et comment les restaurer sur un nouveau serveur.

Sauvegarde & Restauration

Toutes les données stockées par Conzent résident dans des volumes Docker et un fichier de configuration. Cette page couvre ce qui vaut la peine d'être sauvegardé, comment l'automatiser, et comment tout récupérer.

Ce qui conserve réellement vos données

Docker Compose crée cinq volumes nommés. Seuls deux contiennent des éléments que vous ne pouvez pas reconstruire.

Volume / fichier Contenu Sauvegarder ?
oci-db-data MariaDB : sites, bannières, journaux de consentement, catégories de cookies, politiques, utilisateurs, résultats de scan Oui — c'est tout
app-sites-data Scripts de consentement générés Oui, bien que régénérables
.env Mot de passe de la base de données, clé du scanner, identifiants tiers Oui — irremplaçable
app-public Actifs CSS/JS construits Non — reconstruits à partir de l'image
app-var Cache et journaux Non
oci-redis-data Séances, file d'attente de tâches, tampon de balise Non — transitoire par conception

scripts/backup.sh capture exactement les trois premiers, plus .conzent-credentials si cela existe encore.

Les scripts de consentement sont inclus car les restaurer permet de maintenir les bannières actives pendant les minutes entre une restauration et une régénération — mais ils ne sont pas la source de vérité. S'ils étaient complètement perdus, php bin/oci scripts:regenerate reconstruit chacun d'eux à partir de la base de données.

Prendre une sauvegarde

bash scripts/backup.sh

Cela écrit backups/conzent-YYYYmmdd-HHMMSS.tar.gz contenant le dump complet de la base de données, les scripts de consentement générés, votre .env, et un manifeste enregistrant quand il a été pris et de quel APP_URL.

bash scripts/backup.sh --output /mnt/backups     # écrire ailleurs
bash scripts/backup.sh --keep 14                 # garder seulement les 14 archives les plus récentes

Le dump utilise --single-transaction, donc les tables InnoDB sont capturées de manière cohérente sans bloquer les écritures. Il n'est pas nécessaire d'arrêter l'application d'abord.

L'archive contient votre base de données et vos secrets. Elle est écrite en mode 600. Traitez-la comme un fichier de mot de passe : conservez-la hors du serveur, et cryptez-la si elle se trouve quelque part partagé.

Automatisation

Une sauvegarde nocturne à 03:00, conservant deux semaines :

0 3 * * * cd /path/to/conzent && /bin/bash scripts/backup.sh --keep 14 >> /var/log/conzent-backup.log 2>&1

Utilisez le chemin absolu vers votre répertoire d'installation — cron n'hérite pas du répertoire de travail de votre shell.

Une sauvegarde sur le même disque que la base de données n'est pas une sauvegarde. Ajoutez une étape hors site :

15 3 * * * rsync -az /path/to/conzent/backups/ backup-host:/srv/conzent-backups/

Chiffrez avant qu'elle ne parte si la destination n'est pas la vôtre : gpg --symmetric --cipher-algo AES256 backups/conzent-....tar.gz.

Restauration

bash scripts/restore.sh backups/conzent-20260722-030000.tar.gz --yes

--yes est obligatoire — la restauration remplace la base de données actuelle. Ce qu'elle fait, dans l'ordre :

  1. Décompresse et valide l'archive, imprimant son manifeste.
  2. Arrête les conteneurs d'application, laissant MariaDB en cours d'exécution.
  3. Importe le dump dans la base de données nommée dans votre actuel .env.
  4. Restaure le volume des scripts de consentement.
  5. Redémarre tout.
  6. Exécute migrations:migrate, donc une archive plus ancienne est mise à jour au schéma que cette version attend.
  7. Exécute scripts:regenerate, donc les scripts sont reconstruits contre votre actuel APP_URL, et non celui de l'archive.
  8. Vide Redis.

Les étapes 6 et 7 expliquent pourquoi une sauvegarde prise sur old-domain.com se restaure proprement sur une installation maintenant servant consent.example.com.

Par défaut, votre .env existant est laissé intact. Pour prendre également la version de l'archive, ajoutez --restore-env ; votre fichier précédent est conservé sous .env.before-restore-<timestamp>. Utilisez-le lors de la reconstruction d'un serveur perdu, pas lors du retour en arrière des données sur un serveur fonctionnel — le DB_PASSWORD archivé ne correspondra pas à une base de données nouvellement initialisée.

Reconstruire un serveur à partir de zéro

# 1. Installation fraîche sur la nouvelle machine
curl -sSL https://getconzent.com/install | sh -s -- --domain consent.example.com

# 2. Copier l'archive
scp backups/conzent-20260722-030000.tar.gz newhost:/root/conzent/

# 3. Restaurer les données et la configuration
cd /root/conzent
bash scripts/restore.sh conzent-20260722-030000.tar.gz --yes --restore-env

# 4. Si le domaine a changé, définissez-le et régénérez
sed -i 's|^APP_URL=.*|APP_URL=https://consent.example.com|' .env
docker compose up -d
docker compose exec app php bin/oci scripts:regenerate

Effectuer un exercice de restauration

Une sauvegarde non testée est une supposition. Faites cela une fois, avant d'en avoir besoin :

  1. Notez un nom de site, ses paramètres de bannière, et le nombre de journaux de consentement d'aujourd'hui.
  2. Effectuez une sauvegarde.
  3. Sur une machine ou une VM séparée, installez frais et restaurez l'archive.
  4. Connectez-vous et confirmez que le site, la configuration de la bannière, et les journaux de consentement sont tous là.
  5. Chargez une page contenant l'intégration de ce site et vérifiez que la bannière s'affiche toujours.

Dix minutes maintenant, contre la découverte du problème lors d'un incident.

Avant chaque mise à jour

Les mises à jour préservent votre base de données, mais effectuez une sauvegarde d'abord quand même — une migration est la seule chose qu'une restauration ne peut pas annuler :

bash scripts/backup.sh --keep 14 && bash scripts/install.sh --update

La référence complète se trouve avec le code : docs/backup-restore.md sur GitHub.

Retour à la Documentation