Sauvegarde et restauration Docker Compose : exemples pratiques et testés

Intro

Les sauvegardes ne sont utiles que si on peut les restaurer rapidement et de manière reproductible. Ce guide présente des méthodes modernes et testées pour sauvegarder et restaurer des applications Docker Compose. Vous apprendrez exactement quoi protéger, comment capturer les données des services courants (PostgreSQL, Redis, Nginx), comment valider les restaurations et comment planifier la reprise d'activité et le retour arrière. Toutes les commandes sont sûres à exécuter sur un poste de développeur ou un petit hôte de production.

Astuce : exécutez docker compose config pour afficher la configuration effective que Compose utilisera. Cette vue développée aide à auditer les volumes, les variables d'environnement et les montages bind.

Ce qu'il faut sauvegarder

Sauvegardez tout ce qui porte l'état ou définit le fonctionnement de la stack :

Fichiers Compose : docker-compose.yml, les fichiers compose.*.yml d'override et .env.
Configurations des services : configuration Nginx, fichiers de configuration de l'application, certificats et clés TLS.
Volumes nommés : bases de données et tout état de service (par exemple pgdata, redisdata).
Répertoires de données montés en bind : téléchargements de l'application, contenu statique.
Secrets et identifiants : stockez-les de façon sécurisée (pas dans les images) et incluez un export sûr dans votre processus de sauvegarde.
Informations de version : tags d'images (et éventuellement digests) et versions des plugins.

Stack de référence

Utilisez cette stack minimale pour suivre le guide. Adaptez les noms à votre projet.

version: "3.9"
services:
  db:
    image: postgres:16
    environment:
      POSTGRES_USER: app
      POSTGRES_PASSWORD: secret
      POSTGRES_DB: app
    volumes:
      - pgdata:/var/lib/postgresql/data
  redis:
    image: redis:7-alpine
    command: ["redis-server", "--appendonly", "yes\n    volumes:
      - redisdata:/data
  nginx:
    image: nginx:alpine
    ports:
      - "8080:80"
    volumes:
      - ./nginx/conf.d:/etc/nginx/conf.d:ro
      - ./site:/usr/share/nginx/html:ro
volumes:
  pgdata:
  redisdata:

Créez un emplacement pour les sauvegardes et une variable d'horodatage :

mkdir -p backups
TS=$(date -u +%Y%m%d_%H%M%S)

Workflow de sauvegarde (testé)

Un workflow simple et répétable réduit les erreurs :

Inventaire : lister l'état (volumes, montages bind, bases de données, configs d'application, secrets).
Mise en repos si nécessaire : suspendre les écritures ou utiliser les outils de dump natifs du service.
Sauvegarde : capturer données et configs dans une archive horodatée.
Stockage : enregistrer sur un stockage durable, hors hôte.
Vérification : checksum et test de restauration dans un environnement jetable.
Automatisation : scripter et planifier.
Répétition : effectuer une restauration complète régulièrement.

Sauvegarder les fichiers Compose et le contenu bind-monté

# Fichiers Compose et env
tar czf backups/compose_${TS}.tgz docker-compose.yml .env

# Config Nginx et contenu du site (bind mounts)
tar czf backups/nginx_${TS}.tgz nginx/conf.d site

PostgreSQL : privilégier les dumps logiques

Les dumps logiques sont cohérents pendant que la base est en ligne et portables entre hôtes.

Dump au format custom (recommandé : restauration plus rapide, parallélisable) :

# Écrit le dump compressé au format custom sur stdout
PGPASSWORD=secret docker compose exec -T db \
  pg_dump -U app -d app -Fc -Z 6 > backups/pg_app_${TS}.dump

Dump SQL brut (lisible, plus lent à restaurer sur de grosses bases) :

PGPASSWORD=secret docker compose exec -T db \
  pg_dump -U app -d app | gzip > backups/pg_app_${TS}.sql.gz

Snapshot des rôles et objets globaux du cluster (optionnel, utile pour configurations multi‑DB) :

PGPASSWORD=secret docker compose exec -T db \
  pg_dumpall -U app --globals-only > backups/pg_globals_${TS}.sql

Uniquement si indispensable : snapshot brut du répertoire de données. Arrêter les écritures et restaurer sur la même version majeure de Postgres.

# Mise en repos : s'assurer qu'aucun écrivain n'est actif ou arrêter le service db
# docker compose stop app-writers ...

docker compose stop db
# Archiver le répertoire de données depuis un conteneur one‑off avec la même image
docker compose run --rm -T db sh -c 'tar czf - /var/lib/postgresql/data' > backups/pgdata_${TS}.tgz

docker compose up -d db

Redis : capturer AOF/RDB en toute sécurité

Si l'AOF est activé (comme dans cette stack), demandez une réécriture pour obtenir un fichier compact et cohérent ; sinon déclenchez un snapshot en arrière-plan.

# Si AOF utilisé : réécrire le fichier append‑only dans un état cohérent
docker compose exec -T redis redis-cli BGREWRITEAOF

# Si snapshots RDB : en créer un en arrière-plan
# docker compose exec -T redis redis-cli BGSAVE

# Archiver le répertoire de données (contient AOF ou RDB)
docker compose exec -T redis sh -c 'tar czf - /data' > backups/redis_${TS}.tgz

Optionnel : checksums et chiffrement

( cd backups && sha256sum * > SHA256SUMS_${TS}.txt )
# Optionnel : chiffrer les archives avant transfert hors hôte (exemple avec age ou gpg)
# age -r <destinataire> -o backups/pg_app_${TS}.dump.age backups/pg_app_${TS}.dump

Copie hors hôte

Déplacez les sauvegardes hors de l'hôte et, si possible, hors de la région primaire. Utilisez un object store avec politiques de cycle de vie (par exemple : conservation quotidienne 14 jours, hebdomadaire 8 semaines, mensuelle 12 mois). Assurez le chiffrement en transit et les contrôles d'accès.

Workflow de restauration (testé)

Restaurez toujours dans un environnement jetable d'abord. N'écrasez jamais la production avant d'avoir validé.

Mettre en place les configs et démarrer les services de base

# Dans un répertoire de travail propre
mkdir -p nginx/conf.d site

tar xzf backups/compose_${TS}.tgz

tar xzf backups/nginx_${TS}.tgz -C .

docker compose up -d db redis nginx

Restaurer PostgreSQL

Depuis le dump au format custom (rapide, recommandé) :

# Créer la base si absente
PGPASSWORD=secret docker compose exec -T db psql -U app -c 'CREATE DATABASE app;' || true

# Restaurer avec pg_restore (ajouter -j pour parallélisme si la base est grosse)
cat backups/pg_app_${TS}.dump | \
  docker compose exec -T db pg_restore -U app -d app --no-owner --no-privileges

Depuis le dump SQL brut :

gunzip -c backups/pg_app_${TS}.sql.gz | \
  docker compose exec -T db psql -U app -d app

Depuis le snapshot brut du répertoire de données (doit correspondre à la version majeure de Postgres) :

docker compose stop db
# Vider le répertoire de données
docker compose run --rm -T db sh -c 'rm -rf /var/lib/postgresql/data/*'
# Extraire en conservant les chemins absolus du tar
cat backups/pgdata_${TS}.tgz | \
  docker compose run --rm -T db sh -c 'tar xzf - -C /'

docker compose up -d db

Si vous avez sauvegardé les objets globaux (rôles, extensions), appliquez-les avant de restaurer les bases :

[ -f backups/pg_globals_${TS}.sql ] && \
  docker compose exec -T db psql -U app -f /dev/stdin < backups/pg_globals_${TS}.sql || true

Restaurer Redis

docker compose stop redis
# Vider et restaurer le répertoire de données
cat backups/redis_${TS}.tgz | \
  docker compose run --rm -T redis sh -c 'rm -rf /data/* && tar xzf - -C /'
docker compose up -d redis

Recharger Nginx si les configs ont changé

docker compose exec -T nginx nginx -t && \
  docker compose exec -T nginx nginx -s reload

Note : les noms de volumes sous‑projet peuvent inclure un préfixe. L'utilisation de exec ou run sur le service évite de deviner le nom du volume car le conteneur monte déjà le bon volume.

Check‑list de validation

Validez avant de servir le trafic :

Conteneurs sains :

docker compose ps
docker compose logs --since=2m db redis nginx

Santé PostgreSQL :

docker compose exec -T db psql -U app -d app -c \
  "select count(*) as tables from information_schema.tables where table_schema='public';"

Santé Redis :

docker compose exec -T redis redis-cli ping
docker compose exec -T redis redis-cli dbsize

Nginx répond :

curl -I http://localhost:8080/

Vérifications ponctuelles de données : lignes connues, fichiers, comptes utilisateur existent.
Checksums : si vous avez stocké SHA256SUMS, vérifiez-les.

( cd backups && sha256sum -c SHA256SUMS_*.txt )

Accès et permissions : l'application peut lire/écrire où nécessaire.

Question rapide 2 sur 2

Quelle méthode de sauvegarde est recommandée pour les bases de données PostgreSQL lorsque la base est en ligne ?

Le guide indique que les dumps logiques sont cohérents lorsque la base est en ligne et portables, et recommande le dump au format personnalisé (par exemple, pg_dump -Fc) pour une restauration plus rapide.

Reprise d'activité et retour arrière

Planifiez le pire pour que la récupération soit calme et rapide :

RPO (Recovery Point Objective) : objectif de point de récupération : quantité de perte de données acceptable. Adaptez la fréquence de sauvegarde en conséquence.
RTO (Recovery Time Objective) : objectif de temps de récupération : délai maximal pour être de nouveau en ligne. Préchargez les images et tenez les scripts prêts.
Stockage : conservez des copies chiffrées hors hôte ; pour les systèmes critiques, stockez hors région.
Verrouillage des versions : épinglez les tags d'images et évitez la dérive de version majeure entre les restaurations de base de données.
Retour arrière : gardez au moins un snapshot précédent prêt. Si un changement échoue, restaurez la dernière sauvegarde connue bonne et redémarrez les services.
Restauration par étapes : montez une stack parallèle avec un nom de projet différent pour ne pas écraser les volumes de production.

export COMPOSE_PROJECT_NAME=stack_restore_test
docker compose up -d

Runbook : documentez les commandes exactes, emplacements des fichiers et critères de succès. Exercez-vous selon un calendrier.

Automatisation et planification

Commencez par de petits scripts fiables. Exemples de squelettes :

# backup.sh
set -euo pipefail
TS=$(date -u +%Y%m%d_%H%M%S)
mkdir -p backups

tar czf backups/compose_${TS}.tgz docker-compose.yml .env

PGPASSWORD=secret docker compose exec -T db pg_dump -U app -d app -Fc -Z 6 > backups/pg_app_${TS}.dump

docker compose exec -T redis redis-cli BGREWRITEAOF || docker compose exec -T redis redis-cli BGSAVE

docker compose exec -T redis sh -c 'tar czf - /data' > backups/redis_${TS}.tgz

tar czf backups/nginx_${TS}.tgz nginx/conf.d site
( cd backups && sha256sum * > SHA256SUMS_${TS}.txt )

# restore.sh
set -euo pipefail
TS="$1" # passer l'horodatage à restaurer, ex. 20250101_120000

tar xzf backups/compose_${TS}.tgz
mkdir -p nginx/conf.d site

tar xzf backups/nginx_${TS}.tgz -C .

docker compose up -d db redis nginx

# Postgres
PGPASSWORD=secret docker compose exec -T db psql -U app -c 'CREATE DATABASE app;' || true
cat backups/pg_app_${TS}.dump | docker compose exec -T db pg_restore -U app -d app --no-owner --no-privileges

# Redis
docker compose stop redis
cat backups/redis_${TS}.tgz | docker compose run --rm -T redis sh -c 'rm -rf /data/* && tar xzf - -C /'
docker compose up -d redis

Planifiez avec votre ordonnanceur système (cron, systemd timers, ou job CI) et poussez les archives hors hôte après création.

Erreurs fréquentes (et correctifs)

Sauvegarder les conteneurs au lieu des données : sauvegardez les volumes, les montages bind et les dumps logiques.
Tar du système de fichiers sur bases de données actives : utilisez les outils de dump natifs sauf si la base est arrêtée.
Oublier .env et les configs : les restaurations diffèrent alors de l'attendu.
Dérive de version : restaurer un répertoire de données Postgres 16 dans Postgres 15 (ou inversement) échouera.
Restaurer dans le mauvais projet : définissez COMPOSE_PROJECT_NAME explicitement pour éviter la création de volumes indésirables.
Ignorer les codes de retour : utilisez set -euo pipefail et validez les checksums.
Absence de politique de rétention : définissez une rotation pour que les vieilles sauvegardes n'écrasent pas les nouvelles ou ne saturent pas le stockage.
Laisser les services écrire pendant la sauvegarde : mettez en repos les écrivains ou utilisez les outils de dump natifs.

Conclusion

Une sauvegarde Docker Compose fiable est un processus documenté, automatisé et restaurable à la demande. Protégez les configs et l'environnement, employez les outils natifs des services pour des données cohérentes, archivez volumes et montages bind, et validez les restaurations avec des vérifications concrètes. Commencez par un projet pilote, mesurez le succès, puis automatisez dès que vous faites confiance aux étapes. Épinglez les versions, stockez des copies hors hôte et répétez les restaurations complètes pour pouvoir les exécuter sereinement le moment venu.