Tutoriel : Sauvegarder automatiquement ses volumes Docker et bases de données vers S3

Pourquoi les sauvegardes sont non-négociables

Un VPS est un serveur physique dans un datacenter. Ses disques durs peuvent tomber en panne. Les snapshots proposés par les hébergeurs manquent souvent de fiabilité ou de fréquence pour protéger correctement vos données applicatives.

Les erreurs de mise à jour, suppressions accidentelles et pannes matérielles entraînent toutes des pertes de données. Si vous n’avez pas de sauvegarde testée et restaurable, vous n’avez pas de sauvegarde.

⚠️ La Règle N°1 du Sysadmin

Une sauvegarde que vous n'avez jamais restaurée n'existe pas. Planifiez un test de restauration au moins une fois par mois. Beaucoup de scripts de backup produisent des fichiers corrompus ou incomplets sans jamais générer d'erreur.

Il existe deux approches pour sécuriser ces données : utiliser la fonction intégrée à Coolify, ou passer par un script Bash personnalisé pour contrôler finement les volumes Docker.

Choisir son stockage S3 : des alternatives gratuites ou quasi-gratuites

Un bucket S3 compatible est nécessaire pour stocker ces archives. AWS n’est pas obligatoire.

Pour un homelab ou un petit projet, trois options se distinguent :

Backblaze B2 : 10 Go gratuits, puis environ $0,006/Go/mois. API S3 native, facturation en USD.
Scaleway Object Storage : Tarif standard à ~0,0000103 €/Go/heure, avec 75 Go d’egress gratuits par mois. Facturation en EUR, datacenter parisien.
OVHcloud Object Storage : Offre similaire, hébergée en France, bien intégrée à l’écosystème OVH.

J’utilise Scaleway dans ce tutoriel. La procédure reste la même avec Backblaze B2 ou OVH, car ils exposent tous une API compatible S3.

Créez votre bucket et notez votre endpoint (ex: s3.fr-par.scw.cloud), votre région, votre Access Key et votre Secret Key.

Méthode 1 : Les backups intégrées de Coolify (recommandée pour les BDD)

Coolify intègre nativement la sauvegarde automatique vers S3 pour les bases de données PostgreSQL, MySQL ou MariaDB.

Étape 1 : Connecter votre stockage S3 à Coolify

Dans l’interface Coolify :

Allez dans Settings > S3 Storages
Cliquez sur Add et remplissez les champs :
- Endpoint : https://s3.fr-par.scw.cloud (ou l’endpoint de votre provider)
- Region : fr-par
- Access Key et Secret Key : vos identifiants S3
- Bucket : le nom de votre bucket
Cliquez sur Test pour vérifier la connexion, puis Save.

Étape 2 : Activer les backups sur votre base de données

Une fois le stockage configuré :

Dans le menu Resources, sélectionnez votre service de base de données (PostgreSQL, MySQL…)
Cliquez sur l’onglet Backup
Cochez S3 Enabled, sélectionnez le storage que vous venez de créer
Définissez une expression cron pour la fréquence (ex: 0 2 * * * pour chaque nuit à 2h)
Sauvegardez et lancez un premier backup manuel via Run Backup pour vérifier.

Coolify utilise en interne pg_dump avec les options --format=custom --no-acl --no-owner pour PostgreSQL. Cela produit des fichiers .dmp directement restaurables via pg_restore.

💡 Astuce

Si votre base de données est déployée en tant que service attaché à une application (ex: n8n avec son PostgreSQL), allez dans l'onglet de la ressource n8n, trouvez le service PostgreSQL associé, et accédez à son onglet Backup. La configuration est identique.

Méthode 2 : Script Bash custom (volumes + BDD hors Coolify)

Coolify ne gère pas les sauvegardes de volumes Docker (données de fichiers, uploads, configurations persistantes). Un script Bash permet de combler ce manque.

Prérequis

Installez awscli sur votre serveur. Il fonctionne avec n’importe quel fournisseur compatible S3 :

sudo apt update && sudo apt install -y awscli

Configurez vos identifiants S3 :

aws configure
# Entrez votre Access Key, Secret Key, région et format de sortie (json)

Le script de sauvegarde complet

Créez le fichier /opt/scripts/backup-docker-s3.sh :

#!/bin/bash
# ============================================================
# Script de sauvegarde : BDD PostgreSQL/MySQL + Volumes Docker
# Destination : stockage S3 compatible (Scaleway, Backblaze, OVH)
# ============================================================

# --- Configuration ---
S3_BUCKET="s3://mon-bucket-backups"
S3_ENDPOINT="https://s3.fr-par.scw.cloud"
BACKUP_DIR="/tmp/docker-backups"
DATE=$(date +"%Y-%m-%d_%H-%M-%S")
RETENTION_DAYS=7

# --- Credentials S3 (ou utiliser aws configure) ---
export AWS_ACCESS_KEY_ID="VOTRE_ACCESS_KEY"
export AWS_SECRET_ACCESS_KEY="VOTRE_SECRET_KEY"
export AWS_DEFAULT_REGION="fr-par"

# --- Noms des conteneurs et volumes ---
PG_CONTAINER="nom_du_conteneur_postgres"
PG_USER="postgres"
PG_DB="nom_de_la_base"

MYSQL_CONTAINER="nom_du_conteneur_mysql"
MYSQL_USER="root"
MYSQL_PASSWORD="votre_mot_de_passe_mysql"
MYSQL_DB="nom_de_la_base_mysql"

VOLUME_PATH="/var/lib/docker/volumes/nom_du_volume/_data"

# --- Préparation ---
mkdir -p "$BACKUP_DIR"
echo "🚀 Démarrage de la sauvegarde : $DATE"

# --- 1. Dump PostgreSQL ---
echo "📦 Dump PostgreSQL en cours..."
PG_DUMP_FILE="$BACKUP_DIR/pg_${PG_DB}_${DATE}.dump"
docker exec "$PG_CONTAINER" pg_dump \
  --format=custom \
  --no-acl \
  --no-owner \
  --username "$PG_USER" \
  "$PG_DB" > "$PG_DUMP_FILE"

if [ $? -eq 0 ]; then
  gzip "$PG_DUMP_FILE"
  echo "✅ PostgreSQL : OK → ${PG_DUMP_FILE}.gz"
else
  echo "❌ ERREUR : Dump PostgreSQL échoué !"
fi

# --- 2. Dump MySQL/MariaDB ---
echo "📦 Dump MySQL en cours..."
MYSQL_DUMP_FILE="$BACKUP_DIR/mysql_${MYSQL_DB}_${DATE}.sql"
docker exec "$MYSQL_CONTAINER" mysqldump \
  -u "$MYSQL_USER" \
  -p"$MYSQL_PASSWORD" \
  "$MYSQL_DB" > "$MYSQL_DUMP_FILE"

if [ $? -eq 0 ]; then
  gzip "$MYSQL_DUMP_FILE"
  echo "✅ MySQL : OK → ${MYSQL_DUMP_FILE}.gz"
else
  echo "❌ ERREUR : Dump MySQL échoué !"
fi

# --- 3. Compression du volume Docker ---
echo "📁 Compression du volume Docker..."
VOLUME_ARCHIVE="$BACKUP_DIR/volume_${DATE}.tar.gz"
tar -czf "$VOLUME_ARCHIVE" -C "$VOLUME_PATH" .

if [ $? -eq 0 ]; then
  echo "✅ Volume : OK → $VOLUME_ARCHIVE"
else
  echo "❌ ERREUR : Compression du volume échouée !"
fi

# --- 4. Upload vers S3 ---
echo "☁️  Upload vers S3 en cours..."
aws s3 sync "$BACKUP_DIR" "$S3_BUCKET/$(hostname)/" \
  --endpoint-url "$S3_ENDPOINT" \
  --storage-class STANDARD

echo "✅ Upload S3 terminé."

# --- 5. Nettoyage local ---
find "$BACKUP_DIR" -type f -mtime +1 -delete
echo "🧹 Fichiers temporaires locaux nettoyés."

echo "✅ Sauvegarde complète terminée : $DATE"

Rendez le script exécutable :

chmod +x /opt/scripts/backup-docker-s3.sh

Testez-le manuellement une première fois :

/opt/scripts/backup-docker-s3.sh

⚠️ Attention aux credentials dans les scripts

Ne committez jamais ce script avec vos clés S3 dans un dépôt Git public. Préférez stocker vos secrets dans un fichier `/etc/backup.env` avec les permissions `600`, puis chargez-le avec `source /etc/backup.env` en début de script.

Automatisation avec Cron

Éditez la crontab du système ou de root pour avoir accès au socket Docker :

sudo crontab -e

Ajoutez cette ligne pour une sauvegarde quotidienne à 2h30 du matin :

# Sauvegarde Docker + BDD vers S3 : tous les jours à 2h30
30 2 * * * /opt/scripts/backup-docker-s3.sh >> /var/log/backup-docker-s3.log 2>&1

La syntaxe 30 2 * * * signifie « à la 30e minute, de la 2e heure, de n’importe quel jour du mois, de n’importe quel mois, de n’importe quel jour de la semaine ».

Configurez également une rotation des anciennes sauvegardes dans votre bucket S3. Scaleway et Backblaze permettent de définir des règles de cycle de vie pour supprimer automatiquement les fichiers de plus de 30 jours, ce qui limite les coûts.

🛡️ Astuce Sécurité

Limitez les permissions IAM/S3 de votre clé de sauvegarde au strict nécessaire : un accès en écriture uniquement sur votre bucket de backup. Si votre serveur est compromis, l'attaquant n'aura pas accès aux autres buckets et ne pourra pas supprimer les sauvegardes existantes.

Tester la restauration

Testez votre restauration dans un environnement vierge.

Pour restaurer un dump PostgreSQL depuis votre fichier .dump.gz :

# Décompresser
gunzip pg_ma_base_2026-05-22_02-30-00.dump.gz

# Restaurer dans un conteneur PostgreSQL
docker exec -i nom_du_conteneur_postgres pg_restore \
  --verbose \
  --clean \
  -U postgres \
  -d nom_de_la_base \
  pg_ma_base_2026-05-22_02-30-00.dump

Pour restaurer un volume Docker depuis l’archive tar :

# Arrêter le conteneur concerné
docker stop nom_du_conteneur

# Restaurer le contenu du volume
tar -xzf volume_2026-05-22_02-30-00.tar.gz \
  -C /var/lib/docker/volumes/nom_du_volume/_data/

# Redémarrer
docker start nom_du_conteneur

⚠️ Planifiez vos tests de restauration

Bloquez un créneau par mois pour restaurer une sauvegarde dans un environnement de test. C'est la seule garantie que vos données sont récupérables le jour où vous en aurez vraiment besoin.

Récapitulatif de la stratégie

La stratégie complète s’articule ainsi :

Coolify Backup activé sur toutes les bases de données gérées, vers S3 toutes les nuits à 2h.
Script Bash custom pour les volumes Docker non gérés par Coolify, vers S3 toutes les nuits à 2h30.
Rétention : 7 jours de backups quotidiens, plus 1 backup mensuel conservé 3 mois.
Test de restauration : premier dimanche de chaque mois sur un VPS jetable.
Bucket S3 : Scaleway Paris, avec règle de cycle de vie configurée pour la suppression automatique.

Cette combinaison assure un RPO (Recovery Point Objective) de 24 heures et un RTO (Recovery Time Objective) de 15 à 30 minutes.

📚 Pour aller plus loin

Installer Coolify sur un VPS Hostinger : Coolify intègre nativement les sauvegardes de bases de données vers S3, sans écrire une seule ligne de script.
Surveiller ses apps avec Uptime Kuma : Une sauvegarde vous protège de la perte de données, mais un monitoring en temps réel vous alerte dès qu’un service tombe.
Sécuriser son VPS Linux : Protégez l’accès à votre serveur pour que vos sauvegardes et vos données restent sous votre seul contrôle.