Sauvegarde et migration des volumes Docker : guide pratique en 3 méthodes

L’an dernier, lors du Double 11, l’entreprise a migré d’Alibaba Cloud vers Tencent Cloud. Quand le patron a demandé comment gérer les données des bases Docker — un conteneur PostgreSQL actif depuis des mois, plusieurs Go de données utilisateur, jamais sauvegardé.

Ce soir-là, j’ai fouillé frénétiquement les méthodes de sauvegarde Docker. docker cp, tar, l’outil docker-volume-backup… de plus en plus confus. Chaque méthode semblait correcte, mais laquelle choisir ? Et oser tester en production ? Le pire : une sauvegarde pendant des écritures actives, et vous obtenez un fichier corrompu.

Après quelques erreurs, j’ai compris. La sauvegarde Docker n’est pas si complexe — l’essentiel est de savoir quelle méthode convient à quel scénario. Cet article présente 3 approches courantes : quand les utiliser, comment, et quels pièges éviter. À la fin, vous saurez sauvegarder vos applications Docker de façon fiable.

Pourquoi la sauvegarde Docker est importante

Mécanisme de stockage des données

Au début avec Docker, on ne pense pas toujours au stockage. Le conteneur démarre, les données sont là — tout va bien. Mais un point souvent ignoré : le conteneur est éphémère.

Les données écrites directement dans le conteneur disparaissent au redémarrage ou à la mise à jour de l’image. Docker propose deux modes de persistance :

• Volume : espace géré par Docker, sous /var/lib/docker/volumes/. Recommandé officiellement — Docker gère permissions et cycle de vie.
• Bind Mount : répertoire hôte monté dans le conteneur. Ex. /home/user/data → /data dans le conteneur. Sauvegarde directe avec cp.

Données à sauvegarder en priorité :

• Fichiers de bases de données (PostgreSQL, MySQL, MongoDB)
• Fichiers uploadés (avatars, documents, images)
• Fichiers de configuration (certaines configs sensibles méritent une sauvegarde)
• Logs (si vous analysez l’historique)

Scénarios courants de perte de données

Les accidents que j’ai vus ou entendus :

Suppression accidentelle de conteneur. Le plus fréquent. Vous voulez supprimer un conteneur de test, un docker rm -v efface aussi le volume associé. Ce -v est le coupable — il supprime les volumes anonymes liés. Ma première fois en environnement de test : base de données disparue.

Panne de disque. Serveur actif depuis deux ou trois ans, alerte SMART, changement urgent de disque. Les données sont récupérables, mais l’angoisse reste. Avec des sauvegardes régulières, nouveau disque + restauration, opérationnel en une heure.

Migration serveur. Comme au début : changement de datacenter, de cloud provider, ou passage VPS → Kubernetes. Sans sauvegarde, vous priez pour que le scp ne coupe pas.

Cas réel : l’an dernier, une startup — conteneur base de données planté. Au redémarrage, volume corrompu, PostgreSQL ne démarre plus. Dernière sauvegarde : deux mois. Deux mois de commandes perdues, des centaines de milliers de pertes.

Ce n’est pas pour effrayer, mais pour insister : les sauvegardes régulières comptent. Données perdues, la technique ne rattrape pas tout.

3 méthodes de sauvegarde en détail

Méthode 1 : sauvegarde avec tar (⭐⭐⭐⭐⭐ recommandé)

Ma méthode la plus utilisée, adaptée à tous les scénarios. Principe : monter le volume dans un conteneur temporaire et archiver avec tar.

Commande de sauvegarde :

docker run --rm \
  -v postgres_data:/data:ro \
  -v $(pwd):/backup \
  ubuntu tar czf /backup/postgres-backup-20251217.tar.gz -C /data .

Décomposition :

• --rm : suppression automatique après exécution
• -v postgres_data:/data:ro : volume en lecture seule (:ro)
• -v $(pwd):/backup : répertoire courant pour le fichier de sauvegarde
• tar czf : c = créer, z = gzip, f = nom de fichier
• -C /data . : depuis /data, tout le contenu (.)

Commande de restauration :

docker run --rm \
  -v postgres_data:/data \
  -v $(pwd):/backup \
  ubuntu tar xzf /backup/postgres-backup-20251217.tar.gz -C /data

x = extraire, le reste similaire.

Quand l’utiliser ?

• Tous types de volumes, le plus universel
• Compression pour économiser l’espace (30-50 %)
• Transfert vers autre serveur ou stockage cloud

Points d’attention :

Ma première erreur : sauvegarder MySQL en cours d’exécution. La sauvegarde a réussi, mais à la restauration la base ne démarre pas — tables corrompues. Une sauvegarde pendant des écritures peut capturer un état incohérent.

KiloClaw - OpenClaw managé pour l’entreprise : orchestration d’agents IA et routage intelligent

Commencer →Pub

Approche la plus sûre :

1. Arrêter les écritures (arrêt conteneur ou verrouillage tables)
2. Sauvegarder
3. Reprendre les écritures

Si l’arrêt est impossible, assurez-vous que journal ou WAL est actif — la base peut se réparer après restauration.

Cas pratique : sauvegarder PostgreSQL

# 1. Arrêter PostgreSQL (si possible)
docker stop my-postgres

# 2. Sauvegarder le volume
docker run --rm \
  -v postgres_data:/data:ro \
  -v /backup:/backup \
  ubuntu tar czf /backup/pg-$(date +%Y%m%d-%H%M%S).tar.gz -C /data .

# 3. Vérifier le fichier
ls -lh /backup/pg-*.tar.gz

# 4. Redémarrer
docker start my-postgres

J’ajoute un horodatage au nom — on voit tout de suite quand la sauvegarde a été faite.

Méthode 2 : docker cp (⭐⭐⭐)

Plus direct : pas d’archivage, copie des fichiers. Idéal pour quelques configs ou petits répertoires.

Sauvegarde :

# 1. Conteneur temporaire avec le volume
docker create -v nginx_config:/data --name temp_backup busybox

# 2. Copier vers l'hôte
docker cp temp_backup:/data ./nginx-config-backup

# 3. Nettoyer
docker rm temp_backup

Restauration :

# Restaurer vers un nouveau conteneur
docker cp ./nginx-config-backup/. my-nginx:/etc/nginx/

Quand l’utiliser ?

• Quelques fichiers de configuration
• Fichiers modestes (quelques dizaines de Mo)
• Consulter le contenu sans décompresser

Inconvénients :

• Pas de compression, gros fichiers encombrants
• Transfert plus lent que tar
• Permissions et attributs spéciaux parfois mal conservés

Cas pratique : sauvegarder la config Nginx

# Conteneur temporaire
docker create -v nginx_config:/config --name nginx_temp busybox

# Copier la config
docker cp nginx_temp:/config/nginx.conf ./backup/

# Ou tout le répertoire
docker cp nginx_temp:/config/. ./backup/nginx-config/

# Nettoyer
docker rm nginx_temp

Pour les configs : avant de modifier Nginx, un docker cp de secours — restauration rapide si ça casse.

Méthode 3 : docker-volume-backup (⭐⭐⭐⭐ choix automatisation)

Les deux méthodes précédentes sont manuelles. En production, vous voulez des sauvegardes planifiées — là, les outils entrent en jeu.

J’utilise offen/docker-volume-backup, solution open source populaire en 2025 :

• Planification cron
• Arrêt automatique des conteneurs avant sauvegarde (cohérence)
• Backends multiples (S3, Google Drive, SSH, WebDAV)
• Nettoyage des anciennes sauvegardes

Exemple Docker Compose :

version: '3.8'

services:
  # Votre service base de données
  postgres:
    image: postgres:15
    volumes:
      - db_data:/var/lib/postgresql/data
    labels:
      # Arrêter ce conteneur pendant la sauvegarde
      - "docker-volume-backup.stop-during-backup=true"

  # Service de sauvegarde
  backup:
    image: offen/docker-volume-backup:latest
    environment:
      # Tous les jours à 2 h
      BACKUP_CRON_EXPRESSION: "0 2 * * *"
      BACKUP_FILENAME: "db-backup-%Y%m%d-%H%M%S.tar.gz"
      # Conserver 7 jours
      BACKUP_RETENTION_DAYS: "7"
    volumes:
      - db_data:/backup/db_data:ro
      - ./backups:/archive
      - /var/run/docker.sock:/var/run/docker.sock:ro

volumes:
  db_data:

Flux :

1. À 2 h, le conteneur backup démarre
2. Détecte le label stop-during-backup sur postgres, l’arrête
3. Archive db_data avec tar
4. Sauvegarde dans ./backups
5. Redémarre postgres
6. Supprime les sauvegardes de plus de 7 jours

Quand l’utiliser ?

• Production, sauvegardes automatiques
• Envoi vers cloud (S3, GCS, etc.)
• Plusieurs conteneurs à gérer

Points d’attention :

À la première config, vérifiez les permissions. /var/run/docker.sock doit être lisible par le conteneur backup, sinon il ne peut pas arrêter les autres conteneurs.

L’outil arrête vraiment le service quelques secondes à dizaines de secondes (selon le volume). Service non interruptible ? Retirez le label — mais acceptez le risque d’état incohérent.

Cas pratique : sauvegarde automatique MongoDB

version: '3.8'

services:
  mongodb:
    image: mongo:7
    volumes:
      - mongo_data:/data/db
    labels:
      - "docker-volume-backup.stop-during-backup=true"

  backup:
    image: offen/docker-volume-backup:latest
    environment:
      BACKUP_CRON_EXPRESSION: "0 3 * * *"
      BACKUP_FILENAME: "mongo-%Y%m%d.tar.gz"
      BACKUP_RETENTION_DAYS: "14"
      AWS_S3_BUCKET_NAME: "my-backups"
      AWS_ACCESS_KEY_ID: "${AWS_KEY}"
      AWS_SECRET_ACCESS_KEY: "${AWS_SECRET}"
    volumes:
      - mongo_data:/backup/mongo_data:ro
      - /var/run/docker.sock:/var/run/docker.sock:ro

volumes:
  mongo_data:

Sauvegarde MongoDB à 3 h, upload S3, rien en local. Stable depuis plus de six mois chez moi.

Flux complet de migration de données

Étapes pratiques de migration serveur

Après les méthodes de sauvegarde, le flux complet de migration. Mon expérience Alibaba Cloud → Tencent Cloud :

1. Phase de préparation (ne pas sauter)

Cartographier l’environnement :

# Lister tous les conteneurs
docker ps -a

# Lister tous les volumes
docker volume ls

# Exporter la config de chaque conteneur (important !)
docker inspect my-postgres > postgres-config.json
docker inspect my-nginx > nginx-config.json

# Sauvegarder docker-compose.yml et .env
cp docker-compose.yml docker-compose.backup.yml
cp .env .env.backup

Ces fichiers sont essentiels. Première migration : j’avais oublié les variables d’environnement — mot de passe base incorrect sur le nouveau serveur, longues heures perdues.

2. Phase de sauvegarde

Arrêter les services, sauvegarder :

# Arrêter tous les conteneurs
docker-compose down

# Sauvegarder chaque volume
docker run --rm \
  -v postgres_data:/data:ro \
  -v $(pwd)/backups:/backup \
  ubuntu tar czf /backup/postgres_data.tar.gz -C /data .

docker run --rm \
  -v nginx_config:/data:ro \
  -v $(pwd)/backups:/backup \
  ubuntu tar czf /backup/nginx_config.tar.gz -C /data .

# Vérifier les fichiers
ls -lh backups/
md5sum backups/*.tar.gz > backups/checksums.txt

Le md5sum est crucial — en cas de corruption réseau pendant le transfert, vous le détectez.

3. Phase de migration

Transférer vers le nouveau serveur :

🔥 Ne perdez plus des mois sur des produits sans demande ! Validez vos promesses SaaS avec Adsterra à petit budget →

Tester l'MVP →Pub

# rsync avec reprise
rsync -avP --partial backups/ user@new-server:/tmp/backups/

# ou scp
scp -r backups/ user@new-server:/tmp/backups/

Fichiers très volumineux (dizaines de Go) et réseau instable ? Passez par un stockage objet (S3, OSS) — plus rapide et fiable.

Restauration sur le nouveau serveur :

# 1. Créer les volumes
docker volume create postgres_data
docker volume create nginx_config

# 2. Restaurer
docker run --rm \
  -v postgres_data:/data \
  -v /tmp/backups:/backup \
  ubuntu tar xzf /backup/postgres_data.tar.gz -C /data

docker run --rm \
  -v nginx_config:/data \
  -v /tmp/backups:/backup \
  ubuntu tar xzf /backup/nginx_config.tar.gz -C /data

# 3. Vérifier
docker run --rm -v postgres_data:/data ubuntu ls -lh /data

# 4. Démarrer
docker-compose up -d

4. Phase de validation

Ne basculez pas le trafic tout de suite :

# État des conteneurs
docker ps

# Logs sans erreur
docker-compose logs -f

# Test connexion base
docker exec -it my-postgres psql -U postgres -c "SELECT COUNT(*) FROM users;"

# Comparer ancien et nouveau serveur
# (souvent un script comparant les comptages de tables clés)

Tout OK ? Modifiez DNS ou load balancer.

Piège personnel :

Volume de 50 Go — docker run tar pour extraire : près d’une heure. Alternative plus rapide : docker volume create puis extraction directe dans /var/lib/docker/volumes/volume_name/_data sur l’hôte. Attention aux permissions.

Points spéciaux pour les bases de données

La sauvegarde de bases de données est un piège à part.

Pourquoi la sauvegarde au niveau fichier n’est pas toujours fiable ?

Une base en cours d’exécution écrit en permanence. InnoDB (MySQL) a redo/undo log, PostgreSQL a WAL — tout pour la cohérence transactionnelle. Un tar pendant une transaction peut produire un état incohérent.

Cas extrême : sauvegarde MySQL pendant une grosse transaction (millions d’insertions). Fichier apparemment normal, mais InnoDB corrompu à la restauration.

Bonne approche : sauvegarde applicative

PostgreSQL :

# Sauvegarder une base
docker exec my-postgres pg_dump -U postgres mydb > mydb-backup.sql

# Toutes les bases
docker exec my-postgres pg_dumpall -U postgres > all-dbs-backup.sql

# Restauration
docker exec -i my-postgres psql -U postgres mydb < mydb-backup.sql

MySQL :

# Sauvegarde
docker exec my-mysql mysqldump -u root -p mydb > mydb-backup.sql

# Restauration
docker exec -i my-mysql mysql -u root -p mydb < mydb-backup.sql

MongoDB :

# Sauvegarde
docker exec my-mongo mongodump --out=/backup
docker cp my-mongo:/backup ./mongo-backup

# Restauration
docker cp ./mongo-backup my-mongo:/backup
docker exec my-mongo mongorestore /backup

Double stratégie :

Ma pratique actuelle : sauvegarde applicative + sauvegarde volume.

• Applicative (pg_dump, etc.) : restauration principale, cohérence garantie
• Volume (tar) : secours catastrophe si la sauvegarde applicative échoue

Plus d’espace, mais plus sûr. L’ami dont la startup a perdu des données n’avait que le volume — corrompu à la restauration, pas de pg_dump.

Bonnes pratiques et pièges à éviter

Conception de la stratégie de sauvegarde

Méthodes en place ? Il faut une stratégie — trop fréquent = gaspillage, trop rare = perte de données.

Règle 3-2-1 (référence du secteur) :

• 3 copies : données originales + 2 sauvegardes
• 2 supports : disque local + cloud, ou deux disques distincts
• 1 copie hors site : au moins une sauvegarde géographiquement distante

Ma mise en œuvre :

• Serveur local : 7 jours de sauvegardes quotidiennes (copie 1)
• NAS : 30 jours (copie 2, support différent)
• S3 : 3 mois de sauvegardes mensuelles (copie 3, hors site)

Fréquence recommandée :

Convention de nommage :

<service>-<type>-<YYYYMMDD>-<HHMMSS>.tar.gz

Exemples :

myapp-postgres-20251217-020000.tar.gz
myapp-nginx-config-20251217-020000.tar.gz
myapp-uploads-20251217-020000.tar.gz

Tri naturel par date, identification immédiate.

Problèmes courants et solutions

Problème 1 : volume is in use

Rare — un volume peut être monté sur plusieurs conteneurs. Si ça arrive :

• Verrou de fichier
• Problème NFS ou stockage réseau

Solution :

Vultr - Serveur cloud NVMe haute performance, 32 emplacements mondiaux, déploiement Docker en un clic

Voir les tarifs →Pub

# Quels conteneurs utilisent ce volume
docker ps --filter volume=my_volume

# Arrêter si possible
docker stop container_name

# Ou --volumes-from
docker run --rm --volumes-from=my_container -v $(pwd):/backup ubuntu tar czf /backup/data.tar.gz -C /data .

Problème 2 : permissions incorrectes après restauration

Fréquent en migration entre systèmes (Ubuntu → CentOS) — UID/GID différents.

Symptôme : conteneur ne démarre pas, erreur de permission.

Solution :

# Spécifier le propriétaire à la restauration
docker run --rm -v my_volume:/data -v $(pwd):/backup ubuntu sh -c "tar xzf /backup/data.tar.gz -C /data && chown -R 999:999 /data"

# 999:999 = utilisateur postgres dans l'image PostgreSQL
# UID variable selon l'image — consulter la doc ou docker inspect

Problème 3 : fichier de sauvegarde trop volumineux

50 Go MySQL, 30 Go après gzip — transfert public lent et instable.

Solutions :

1. Meilleure compression : xz, 20-30 % de plus que gzip, plus lent

   tar cJf backup.tar.xz /data  # J = xz

2. Volumes fractionnés :

   tar czf - /data | split -b 1G - backup.tar.gz.
   # Restauration : cat backup.tar.gz.* | tar xzf -

3. Sauvegarde incrémentale : rsync ou logiciel dédié

Problème 4 : fichier corrompu à la restauration

Le pire — découverte au moment critique.

Prévention :

# Vérifier immédiatement après sauvegarde
md5sum backup.tar.gz > backup.tar.gz.md5

# Revérifier après transfert
md5sum -c backup.tar.gz.md5

# Tester la restauration régulièrement (le plus important !)
# Chaque mois sur un environnement de test

Mon habitude : après chaque sauvegarde, extraire les premiers fichiers pour confirmer l’intégrité de l’archive.

Automatisation et surveillance

Sauvegarde manuelle fiable, mais on oublie. En production : automatisation obligatoire.

Crontab pour script de sauvegarde :

# Script /opt/scripts/backup-docker-volumes.sh
#!/bin/bash
DATE=$(date +%Y%m%d-%H%M%S)
BACKUP_DIR=/backup

# PostgreSQL
docker run --rm \
  -v postgres_data:/data:ro \
  -v $BACKUP_DIR:/backup \
  ubuntu tar czf /backup/postgres-$DATE.tar.gz -C /data .

# Nginx
docker run --rm \
  -v nginx_config:/data:ro \
  -v $BACKUP_DIR:/backup \
  ubuntu tar czf /backup/nginx-$DATE.tar.gz -C /data .

# Supprimer sauvegardes > 7 jours
find $BACKUP_DIR -name "*.tar.gz" -mtime +7 -delete

# Notification (optionnel)
echo "Backup completed: $DATE" | mail -s "Docker Backup Report" [email protected]

# crontab
crontab -e

# Tous les jours à 2 h
0 2 * * * /opt/scripts/backup-docker-volumes.sh >> /var/log/docker-backup.log 2>&1

Surveillance et alertes :

1. Logs : horodatage, taille, MD5 à chaque sauvegarde
2. Script de contrôle : alerte si aucune nouvelle sauvegarde
3. Taille anormale : variation > 50 % par rapport à la moyenne

Script simple :

#!/bin/bash
BACKUP_DIR=/backup
EXPECTED_SIZE=100000000  # 100 Mo, ajuster selon votre cas

LATEST_BACKUP=$(ls -t $BACKUP_DIR/postgres-*.tar.gz | head -1)
if [ -z "$LATEST_BACKUP" ]; then
  echo "ERROR: No backup file found!"
  exit 1
fi

BACKUP_DATE=$(stat -c %Y "$LATEST_BACKUP")
TODAY=$(date +%s)
AGE=$((TODAY - BACKUP_DATE))

if [ $AGE -gt 86400 ]; then
  echo "ERROR: Latest backup is older than 24 hours!"
  exit 1
fi

SIZE=$(stat -c %s "$LATEST_BACKUP")
if [ $SIZE -lt $(($EXPECTED_SIZE / 2)) ]; then
  echo "WARNING: Backup file is too small: $SIZE bytes"
  exit 1
fi

echo "Backup check passed: $LATEST_BACKUP ($SIZE bytes)"

Intégrable à Prometheus, Zabbix, ou notifications e-mail / messagerie d’entreprise.

Conclusion

Revenons à la question initiale : comment sauvegarder les données Docker ?

Aucune méthode universelle — choisissez selon votre scénario.

• Sauvegarde ponctuelle, migration rapide : tar, fiable et polyvalent
• Configs, petits fichiers : docker cp, simple
• Production, automatisation : docker-volume-backup, serein

Point essentiel : sauvegarder régulièrement, tester la restauration régulièrement. Ne découvrez pas un fichier corrompu le jour J. Chaque mois, je restaure sur un environnement de test.

Conseil : faites votre première sauvegarde aujourd’hui — tar suffit, une fois pour essayer. Un fichier sur le disque, c’est déjà plus serein.

Des questions ou de meilleures méthodes ? Commentaires bienvenus — échangeons pour éviter les pièges.