Sauvegarder et restaurer les volumes Docker sur un VPS

13 min de lecture·Matthieu·cronrclones3mysqlpostgresqlbackupdocker-composedocker|

Trois stratégies de sauvegarde pour les volumes Docker sur un VPS : snapshots tar, dumps natifs de bases de données, et sauvegardes automatisées chiffrées avec offen/docker-volume-backup. Planification cron, copies hors site avec rclone vers S3, et test de restauration complet sur un serveur neuf.

Les volumes nommés Docker contiennent vos données de production : bases de données, fichiers uploadés, état de configuration. Les conteneurs sont jetables. Les volumes ne le sont pas. Si un disque lâche ou qu'une migration tourne mal, ce sont les volumes qu'il vous faut récupérer.

Ce guide couvre trois stratégies de sauvegarde, les automatise avec cron, envoie des copies hors serveur avec rclone, puis prouve que la restauration fonctionne en reconstruisant tout sur un VPS neuf. Si vous n'avez pas testé votre restauration, vous n'avez pas de sauvegardes.

Ce que vous allez apprendre :

  • Snapshots de volumes par tar (simple, universel)
  • Dumps natifs avec pg_dump et mysqldump (cohérents, sans interruption)
  • Sauvegardes automatisées et chiffrées avec offen/docker-volume-backup (planifiées, compatibles S3)
  • Automatisation cron avec politiques de rétention
  • Copies hors serveur vers du stockage compatible S3 via rclone
  • Restauration complète en cas de sinistre sur un VPS neuf

Prérequis

Vous avez besoin d'un VPS sous Debian 12 ou Ubuntu 24.04 avec Docker et Docker Compose v2 installés. Ce guide suppose que vous avez un stack Compose en fonctionnement avec au moins un volume nommé. Si vous devez d'abord mettre cela en place, consultez notre guide Docker Compose multi-services sur un VPS.

Vérifiez votre installation :

docker --version
# Docker version 28.x or newer
docker compose version
# Docker Compose version v2.x or newer

Listez vos volumes existants :

docker volume ls

La sortie affiche chaque volume nommé du système. Identifiez ceux qui contiennent des données importantes. Utilisez docker system df -v pour voir l'espace occupé par chaque volume. Cela aide à estimer la taille des sauvegardes et les besoins en stockage.

Créez un répertoire de sauvegarde avec des permissions restreintes :

mkdir -p /opt/backups/docker
chmod 700 /opt/backups/docker

Seul root peut lire ce répertoire. Les sauvegardes contiennent souvent des identifiants de base de données, des jetons de session ou des données utilisateur.

Comment sauvegarder des volumes Docker sur un VPS ?

Il existe trois stratégies, chacune avec ses compromis. Choisissez en fonction du contenu de vos volumes et du temps d'arrêt que vous pouvez tolérer.

Méthode Interruption Cohérence des données Automatisation Chiffrement Idéal pour
Snapshot tar Brève (conteneur arrêté) Niveau système de fichiers Manuelle ou script cron Non (ajoutez GPG séparément) Fichiers statiques, uploads, config
Dump de base de données Aucune Cohérence transactionnelle Manuel ou script cron Non (ajoutez GPG séparément) PostgreSQL, MySQL, MariaDB
offen/docker-volume-backup Optionnelle (configurable) Niveau système de fichiers Planificateur intégré GPG intégré Tout volume, fonctionnement autonome

Comment créer une sauvegarde tar d'un volume Docker ?

Arrêtez le conteneur qui utilise le volume, lancez un conteneur Alpine temporaire pour archiver le contenu du volume en tar, puis redémarrez. L'opération prend quelques secondes pour la plupart des volumes et fonctionne avec tout type de données.

1. Arrêtez le conteneur qui écrit dans le volume :

# Replace "app" with your service name from docker-compose.yml
docker compose stop app

L'arrêt de l'écriture empêche les écritures partielles pendant l'archivage. Pour les volumes en lecture seule ou les fichiers statiques, vous pouvez sauter cette étape.

2. Créez l'archive tar :

docker run --rm \
  -v myapp_data:/source:ro \
  -v /opt/backups/docker:/backup \
  alpine tar czf /backup/myapp_data-$(date +%Y%m%d-%H%M%S).tar.gz -C /source .

Ce que fait cette commande : elle lance un conteneur Alpine jetable, monte votre volume en lecture seule sur /source, monte le répertoire de sauvegarde sur /backup, et crée une archive tar compressée en gzip. Le flag --rm supprime le conteneur quand il termine. Le flag :ro empêche le processus de sauvegarde d'écrire accidentellement dans vos données.

3. Redémarrez le conteneur :

docker compose start app

4. Vérifiez l'archive :

ls -lh /opt/backups/docker/myapp_data-*.tar.gz

La sortie affiche l'archive avec une taille raisonnable. Un volume de 500 Mo se compresse en général entre 60 et 120 Mo selon le type de données.

Listez le contenu de l'archive pour confirmer que les fichiers sont présents :

tar tzf /opt/backups/docker/myapp_data-20260319-120000.tar.gz | head -20

Ouvrez l'oeil : les chemins doivent commencer par ./ (pas de nom de répertoire en tête). C'est parce que nous avons utilisé -C /source . dans la commande tar. C'est important lors de la restauration.

Comment sauvegarder une base PostgreSQL dans Docker ?

Utilisez pg_dump à l'intérieur du conteneur en cours d'exécution. Cela produit un dump transactionnellement cohérent sans arrêter la base. Le format custom (-Fc) compresse la sortie et permet une restauration sélective.

docker compose exec -T postgres pg_dump \
  -U "$POSTGRES_USER" \
  -Fc \
  --no-owner \
  --no-acl \
  mydb > /opt/backups/docker/mydb-$(date +%Y%m%d-%H%M%S).dump

Ce que fait cette commande : exec -T exécute la commande dans le conteneur postgres en cours d'exécution sans allouer de TTY (nécessaire pour la redirection de sortie). -Fc sélectionne le format custom, qui est compressé et compatible avec pg_restore. --no-owner et --no-acl rendent le dump portable entre différents utilisateurs de base de données.

La variable $POSTGRES_USER doit provenir de votre fichier d'environnement, pas être codée en dur. Si votre stack Compose utilise un fichier env :

source /opt/myapp/.env
docker compose exec -T postgres pg_dump \
  -U "$POSTGRES_USER" \
  -Fc \
  --no-owner \
  --no-acl \
  "$POSTGRES_DB" > /opt/backups/docker/"$POSTGRES_DB"-$(date +%Y%m%d-%H%M%S).dump

Vérifiez le dump en le passant au pg_restore du conteneur :

docker compose exec -T postgres pg_restore --list < /opt/backups/docker/mydb-20260319-120000.dump | head -10

Cela affiche la table des matières sans rien restaurer. Si le fichier est corrompu, pg_restore renverra une erreur. Nous utilisons docker compose exec -T parce que pg_restore se trouve dans le conteneur, pas sur l'hôte (sauf si vous installez postgresql-client séparément).

Comment sauvegarder une base MySQL dans Docker ?

Utilisez mysqldump avec --single-transaction pour les tables InnoDB. Cela donne un snapshot cohérent sans verrouiller la base.

docker compose exec -T mysql mysqldump \
  -u root \
  -p"$MYSQL_ROOT_PASSWORD" \
  --single-transaction \
  --routines \
  --triggers \
  mydb > /opt/backups/docker/mydb-$(date +%Y%m%d-%H%M%S).sql

Le flag -p n'a pas d'espace avant le mot de passe. --single-transaction utilise une lecture cohérente pour les tables InnoDB. --routines et --triggers incluent les procédures stockées et les triggers que mysqldump ignore par défaut.

Vérifiez que le dump n'est pas vide et se termine par le marqueur de fin :

tail -5 /opt/backups/docker/mydb-20260319-120000.sql

La sortie affiche -- Dump completed on YYYY-MM-DD HH:MM:SS. Si le fichier est tronqué ou vide, le dump a échoué.

Comment automatiser les sauvegardes de volumes Docker avec offen/docker-volume-backup ?

offen/docker-volume-backup tourne comme conteneur sidecar dans votre stack Compose. Il sauvegarde les volumes montés selon un planning, chiffre optionnellement les archives avec GPG, et peut envoyer directement vers du stockage compatible S3. Il peut aussi arrêter des conteneurs pendant la sauvegarde pour garantir la cohérence.

Ajoutez le service de sauvegarde à votre docker-compose.yml :

services:
  # ... your existing services ...

  backup:
    image: offen/docker-volume-backup:v2.47.2
    restart: unless-stopped
    env_file:
      - ./backup.env
    volumes:
      - myapp_data:/backup/myapp_data:ro
      - myapp_db:/backup/myapp_db:ro
      - /opt/backups/docker:/archive
      - /var/run/docker.sock:/var/run/docker.sock
    labels:
      - docker-volume-backup.stop-during-backup=false

Ce que fait cette configuration : elle monte chaque volume à sauvegarder sous /backup/ en lecture seule, monte /archive pour le stockage local des sauvegardes, et monte le socket Docker pour que l'outil puisse arrêter et redémarrer les conteneurs si configuré. Le tag d'image v2.47.2 fixe la version. N'utilisez pas latest en production.

Note de sécurité : monter le socket Docker donne au conteneur de sauvegarde un contrôle total sur Docker sur l'hôte. C'est nécessaire pour la fonction d'arrêt pendant la sauvegarde. Si vous n'avez pas besoin de cette fonction, vous pouvez le monter en lecture seule (/var/run/docker.sock:/var/run/docker.sock:ro), ce qui permet à l'outil de lire les labels des conteneurs mais l'empêche de les arrêter ou de les démarrer.

Créez le fichier d'environnement avec des permissions restreintes :

touch /opt/myapp/backup.env
chmod 600 /opt/myapp/backup.env

# /opt/myapp/backup.env
BACKUP_CRON_EXPRESSION=0 3 * * *
BACKUP_RETENTION_DAYS=7
BACKUP_COMPRESSION=gz
BACKUP_FILENAME=backup-%Y%m%dT%H%M%S.tar.gz

# GPG encryption (generate a strong passphrase)
GPG_PASSPHRASE=your-generated-passphrase-here

# S3-compatible storage (optional, see rclone section for alternative)
# AWS_S3_BUCKET_NAME=my-backups
# AWS_S3_PATH=myapp
# AWS_ENDPOINT=s3.eu-central-1.amazonaws.com
# AWS_ACCESS_KEY_ID=
# AWS_SECRET_ACCESS_KEY=

Générez la passphrase GPG :

openssl rand -base64 32

Stockez cette passphrase en lieu sûr en dehors du serveur. Si vous la perdez, les sauvegardes chiffrées sont irrécupérables.

Si vous souhaitez que l'outil de sauvegarde arrête certains conteneurs pendant la sauvegarde pour assurer la cohérence du système de fichiers, ajoutez un label à ces services :

services:
  app:
    # ... your config ...
    labels:
      - docker-volume-backup.stop-during-backup=true

Démarrez le service de sauvegarde :

docker compose up -d backup

Vérifiez qu'il tourne :

docker compose logs backup

La sortie affiche une ligne de log confirmant le planning cron. Attendez la première exécution planifiée, ou déclenchez une sauvegarde manuelle :

docker compose exec backup backup

Vérifiez que l'archive est apparue :

ls -lh /opt/backups/docker/

Comment planifier des sauvegardes Docker avec cron ?

Pour les stratégies tar et dump de base de données, un script shell avec cron gère la planification et la rétention. L'outil offen a son propre planificateur ; passez cette section si vous n'utilisez que celui-là.

Créez le script de sauvegarde :

touch /opt/backups/docker-backup.sh
chmod 700 /opt/backups/docker-backup.sh

#!/usr/bin/env bash
# /opt/backups/docker-backup.sh
# Backs up Docker volumes and databases, removes old archives.

set -euo pipefail

BACKUP_DIR="/opt/backups/docker"
RETENTION_DAYS=7
TIMESTAMP=$(date +%Y%m%d-%H%M%S)
COMPOSE_DIR="/opt/myapp"

# Load database credentials from env file
source "${COMPOSE_DIR}/.env"

cd "$COMPOSE_DIR"

# --- Tar backup of application data volume ---
docker compose stop app
docker run --rm \
  -v myapp_data:/source:ro \
  -v "${BACKUP_DIR}":/backup \
  alpine tar czf "/backup/myapp_data-${TIMESTAMP}.tar.gz" -C /source .
docker compose start app

# --- PostgreSQL dump (no downtime) ---
docker compose exec -T postgres pg_dump \
  -U "$POSTGRES_USER" \
  -Fc --no-owner --no-acl \
  "$POSTGRES_DB" > "${BACKUP_DIR}/${POSTGRES_DB}-${TIMESTAMP}.dump"

# --- Retention: delete backups older than N days ---
find "$BACKUP_DIR" -type f -name "*.tar.gz" -mtime +${RETENTION_DAYS} -delete
find "$BACKUP_DIR" -type f -name "*.dump" -mtime +${RETENTION_DAYS} -delete

echo "[$(date -Iseconds)] Backup completed successfully"

Vérifiez que le script tourne sans erreurs :

/opt/backups/docker-backup.sh

Vérifiez les fichiers produits :

ls -lh /opt/backups/docker/

Ajoutez une entrée cron qui s'exécute à 03h00 quotidiennement et journalise la sortie :

crontab -e

0 3 * * * /opt/backups/docker-backup.sh >> /var/log/docker-backup.log 2>&1

Le 2>&1 redirige stderr vers le même fichier de log, pour que les erreurs soient capturées. Consultez le log après la première exécution :

cat /var/log/docker-backup.log

Si le script échoue, cron avale silencieusement l'erreur sauf si vous redirigez la sortie. Pour recevoir des alertes par mail en cas d'échec, ajoutez ce wrapper :

0 3 * * * /opt/backups/docker-backup.sh >> /var/log/docker-backup.log 2>&1 || echo "Docker backup failed on $(hostname)" | mail -s "BACKUP FAILED" you@example.com

Cela nécessite mailutils ou un paquet similaire. Adaptez l'adresse du destinataire.

Comment copier les sauvegardes Docker vers du stockage compatible S3 avec rclone ?

Les sauvegardes locales protègent contre les pannes applicatives. Elles ne protègent pas contre les pannes de disque ou un serveur compromis. Vous avez besoin de copies hors serveur. rclone fonctionne avec tout stockage compatible S3 : AWS S3, Backblaze B2, Wasabi, MinIO, OVH Object Storage, Scaleway, et d'autres.

Installez rclone :

apt update && apt install -y rclone

Configurez un remote compatible S3 :

rclone config

Suivez les invites interactives :

  1. n pour un nouveau remote
  2. Nommez-le s3backup
  3. Choisissez s3 (Amazon S3 Compliant Storage Providers)
  4. Sélectionnez votre fournisseur (ou « Any other S3 compatible provider »)
  5. Entrez votre clé d'accès et votre clé secrète
  6. Définissez la région et l'URL d'endpoint de votre fournisseur
  7. Laissez les autres options par défaut

Vérifiez que le remote fonctionne :

rclone lsd s3backup:

Cela liste vos buckets. Si ça échoue, vos identifiants ou votre endpoint sont incorrects.

Créez un bucket pour les sauvegardes (si votre fournisseur le supporte via rclone) :

rclone mkdir s3backup:my-docker-backups

Synchronisez votre répertoire de sauvegarde local vers le bucket :

rclone sync /opt/backups/docker s3backup:my-docker-backups/$(hostname)/ \
  --transfers 4 \
  --checkers 8 \
  --log-file /var/log/rclone-backup.log \
  --log-level INFO

Ce que fait cette commande : sync fait correspondre le remote au répertoire local. Les fichiers supprimés localement (par la rétention) sont aussi supprimés côté remote. Le préfixe $(hostname) sépare les sauvegardes si vous avez plusieurs serveurs.

Vérifiez l'upload :

rclone ls s3backup:my-docker-backups/$(hostname)/

La sortie affiche vos fichiers de sauvegarde listés avec des tailles correspondant aux copies locales.

Ajoutez la synchronisation rclone au script de sauvegarde ou comme entrée cron séparée qui s'exécute après la sauvegarde :

30 3 * * * rclone sync /opt/backups/docker s3backup:my-docker-backups/$(hostname)/ --transfers 4 --log-file /var/log/rclone-backup.log --log-level INFO

Cela s'exécute à 03h30, laissant au job de sauvegarde de 03h00 le temps de finir.

Protégez la configuration rclone : elle contient vos identifiants S3.

chmod 600 ~/.config/rclone/rclone.conf
ls -la ~/.config/rclone/rclone.conf

La sortie affiche les permissions -rw-------. Seul root peut lire ce fichier.

Faut-il arrêter les conteneurs avant de sauvegarder les volumes Docker ?

Cela dépend du contenu du volume. Se tromper sur ce point est la cause la plus fréquente de sauvegardes corrompues.

Bases de données (PostgreSQL, MySQL, MongoDB) : n'archivez jamais en tar un volume de base de données en cours d'exécution. Les fichiers sur disque représentent un état de transaction en cours. Un tar de ces fichiers revient à photocopier un livre pendant que quelqu'un en réécrit les chapitres. Le résultat est incohérent en interne. Utilisez plutôt pg_dump, mysqldump ou mongodump. Ces outils produisent un snapshot transactionnellement cohérent pendant que la base continue de tourner.

Données applicatives (uploads, fichiers statiques, config) : tar est sûr si l'application tolère un bref arrêt. Si l'application écrit en continu et que vous ne pouvez pas l'arrêter, le tar peut contenir des fichiers partiellement écrits. Pour la plupart des applications web, un arrêt de 2 secondes pendant une sauvegarde à 3h du matin est acceptable.

Redis, magasins clé-valeur : Redis écrit des snapshots RDB sur disque périodiquement. Déclenchez un BGSAVE avant d'archiver le volume en tar, puis attendez qu'il finisse. Cela vous donne un snapshot cohérent sans arrêter Redis.

docker compose exec redis redis-cli BGSAVE
# Wait a few seconds
docker compose exec redis redis-cli LASTSAVE

Le choix sûr par défaut : en cas de doute, arrêtez le conteneur, sauvegardez, redémarrez. Une brève interruption vaut mieux que des sauvegardes corrompues.

Comment restaurer des volumes Docker sur un nouveau VPS ?

Voici la procédure qui prouve que vos sauvegardes fonctionnent. Installez Docker sur un serveur neuf, transférez les fichiers de sauvegarde, recréez les volumes, restaurez les données, et vérifiez que l'application tourne.

1. Installez Docker sur le nouveau VPS

apt update && apt install -y ca-certificates curl
install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/debian/gpg -o /etc/apt/keyrings/docker.asc
chmod a+r /etc/apt/keyrings/docker.asc

echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] \
  https://download.docker.com/linux/debian $(. /etc/os-release && echo "$VERSION_CODENAME") stable" \
  | tee /etc/apt/sources.list.d/docker.list > /dev/null

apt update && apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Contrôle :

docker --version && docker compose version

2. Transférez les fichiers de sauvegarde vers le nouveau serveur

Depuis votre machine locale ou l'ancien serveur :

rsync -avz --progress /opt/backups/docker/ root@NEW_SERVER_IP:/opt/backups/docker/

Ou téléchargez depuis S3 :

# On the new server, install and configure rclone first
apt install -y rclone
# Re-run rclone config with the same credentials
rclone copy s3backup:my-docker-backups/OLD_HOSTNAME/ /opt/backups/docker/

Vérifiez que les fichiers sont arrivés :

ls -lh /opt/backups/docker/

3. Copiez vos fichiers Compose et fichiers env

rsync -avz /opt/myapp/ root@NEW_SERVER_IP:/opt/myapp/

Ou restaurez-les depuis votre dépôt Git. Votre docker-compose.yml et .env devraient être versionnés. Le fichier .env devrait être dans .gitignore et sauvegardé séparément.

4. Restaurez le volume tar

# Create the volume (Docker Compose will also do this on first `up`,
# but creating it explicitly lets us restore data before starting services)
docker volume create myapp_data

# Restore from archive
docker run --rm \
  -v myapp_data:/target \
  -v /opt/backups/docker:/backup:ro \
  alpine sh -c "cd /target && tar xzf /backup/myapp_data-20260319-030000.tar.gz"

Ce que fait cette commande : elle crée le volume nommé, puis lance un conteneur temporaire qui extrait l'archive dedans. Le répertoire de sauvegarde est monté en lecture seule pour éviter les accidents.

Vérifiez les données restaurées :

docker run --rm -v myapp_data:/data:ro alpine ls -la /data/

La sortie affiche les mêmes fichiers que dans le volume d'origine.

5. Restaurez la base PostgreSQL

Démarrez uniquement le conteneur de base de données :

cd /opt/myapp
docker compose up -d postgres

Attendez qu'il soit prêt :

docker compose logs -f postgres
# Wait until you see "database system is ready to accept connections"

Restaurez le dump :

docker compose exec -T postgres pg_restore \
  -U "$POSTGRES_USER" \
  -d "$POSTGRES_DB" \
  --clean \
  --if-exists \
  --no-owner \
  --no-acl \
  < /opt/backups/docker/mydb-20260319-030000.dump

Ce que fait cette commande : --clean supprime les objets existants avant de les recréer. --if-exists empêche les erreurs si les objets n'existent pas encore. Cela rend la restauration idempotente.

Vérifiez les données :

docker compose exec postgres psql -U "$POSTGRES_USER" -d "$POSTGRES_DB" -c "\dt"

La sortie affiche vos tables listées. Lancez un comptage rapide sur une table connue :

docker compose exec postgres psql -U "$POSTGRES_USER" -d "$POSTGRES_DB" -c "SELECT count(*) FROM your_table;"

6. Démarrez tous les services et vérifiez

docker compose up -d

Vérifiez que tous les conteneurs tournent :

docker compose ps

Chaque service devrait afficher Up ou running. Si un conteneur redémarre en boucle, vérifiez ses logs :

docker compose logs --tail 50 service_name

Testez l'application depuis l'extérieur du serveur. Depuis votre machine locale :

curl -I http://NEW_SERVER_IP:PORT

Vous devriez obtenir une réponse HTTP valide. Si l'application a un endpoint de health check, appelez-le :

curl http://NEW_SERVER_IP:PORT/health

Pour en savoir plus sur les health checks, consultez notre guide sur les limites de ressources et health checks Docker Compose.

Comment vérifier qu'une sauvegarde de volume Docker est valide ?

Une sauvegarde jamais testée est un risque. Effectuez ces vérifications régulièrement, pas seulement en cas de sinistre.

Vérifiez l'intégrité de l'archive :

# For tar.gz files
gzip -t /opt/backups/docker/myapp_data-20260319-030000.tar.gz && echo "OK" || echo "CORRUPT"

Vérifiez le contenu de l'archive :

tar tzf /opt/backups/docker/myapp_data-20260319-030000.tar.gz | wc -l

Comparez le nombre de fichiers avec une sauvegarde de référence. Une chute soudaine du nombre de fichiers indique un problème.

Testez la restauration dans un volume jetable :

docker volume create test_restore
docker run --rm \
  -v test_restore:/target \
  -v /opt/backups/docker:/backup:ro \
  alpine sh -c "cd /target && tar xzf /backup/myapp_data-20260319-030000.tar.gz"

# Inspect the restored data
docker run --rm -v test_restore:/data:ro alpine ls -la /data/

# Clean up
docker volume rm test_restore

Vérifiez un dump de base de données :

docker compose exec -T postgres pg_restore --list < /opt/backups/docker/mydb-20260319-030000.dump | wc -l

Si cela retourne un nombre d'objets (tables, index, séquences), le dump est lisible. Si ça génère une erreur, le fichier est corrompu.

Générez des sommes de contrôle pour le stockage longue durée :

sha256sum /opt/backups/docker/*.tar.gz /opt/backups/docker/*.dump > /opt/backups/docker/checksums-$(date +%Y%m%d).sha256

Envoyez le fichier de sommes de contrôle avec les sauvegardes. Avant de restaurer, vérifiez :

sha256sum -c /opt/backups/docker/checksums-20260319.sha256

Dépannage

« Permission denied » lors de la création de l'archive tar : Le conteneur temporaire tourne en root par défaut, donc cela signifie en général que le répertoire de sauvegarde n'existe pas ou a les mauvaises permissions. Lancez ls -la /opt/backups/ et vérifiez que le sous-répertoire docker existe avec les permissions 700.

pg_dump/pg_restore se bloque : Vous avez probablement oublié le flag -T dans docker compose exec. Sans -T, exec tente d'allouer un TTY, ce qui bloque lors de la redirection de sortie. Utilisez docker compose exec -T.

Les fichiers de sauvegarde font 0 octet : Le conteneur a écrit à un chemin différent de celui attendu. Revérifiez que le nom du volume dans docker volume ls correspond à celui utilisé dans le flag -v. Les volumes nommés sont sensibles à la casse.

rclone sync timeout : Les synchronisations initiales volumineuses peuvent dépasser les timeouts par défaut. Ajoutez --timeout 30m et --retries 3 à la commande rclone.

offen/docker-volume-backup ne s'exécute pas selon le planning : Vérifiez la syntaxe de BACKUP_CRON_EXPRESSION. L'outil utilise la syntaxe cron standard à 5 champs. Lancez docker compose logs backup et cherchez les erreurs d'analyse.

La base restaurée a les mauvaises permissions : Vous avez utilisé un dump sans --no-owner. Le dump tente de définir la propriété à l'utilisateur d'origine, qui peut ne pas exister sur le nouveau serveur. Refaites le dump avec --no-owner --no-acl ou exécutez REASSIGN OWNED BY old_user TO new_user; dans psql.

Pour aller plus loin

  • Configuration complète de Docker en production
  • Health checks pour confirmer que les services sont vivants après une restauration
  • Les bases de la CLI Docker

Copyright 2026 Virtua.Cloud. Tous droits réservés. Ce contenu est une création originale de l'équipe Virtua.Cloud. Toute reproduction, republication ou redistribution sans autorisation écrite est interdite.

Prêt à essayer ?

Déployez Docker avec des sauvegardes automatisées sur votre VPS.

Voir les offres VPS