Sauvegarder ses conteneurs Docker vers Hyperbackup

Une fois la configuration du pare-feu sauvegardée correctement, il reste la partie la plus volumineuse de l'infrastructure : les données des conteneurs eux-mêmes (bases de données, fichiers de configuration, volumes applicatifs). Un simple rsync des volumes en direct, pendant que les conteneurs tournent, produit régulièrement des copies incohérentes — un fichier à moitié écrit, une base de données dans un état intermédiaire. Voici l'approche que j'utilise : un snapshot atomique côté hôte, exporté automatiquement vers le NAS, puis pris en charge par Hyperbackup pour la rétention.

1. Le problème d'une copie à chaud

Copier les fichiers d'un volume Docker pendant que le conteneur écrit dedans n'offre aucune garantie de cohérence : les différents fichiers copiés ne correspondent pas forcément au même instant, et une base de données peut être surprise en plein milieu d'une transaction. Le résultat se restaure parfois sans erreur apparente, mais avec des données corrompues ou incohérentes qu'on ne découvre qu'au moment où on en a besoin — le pire moment possible.

2. L'approche par snapshot atomique

La solution consiste à s'appuyer sur un système de fichiers capable de snapshot instantané — Btrfs (subvolume snapshot) ou LVM (logical volume snapshot) selon ce qui est déjà en place sur l'hôte Docker. Le principe :

1. Arrêter brièvement les conteneurs concernés (ou au minimum s'assurer qu'ils sont dans un état cohérent) ;
2. Prendre un snapshot du volume qui héberge les données — opération quasi instantanée, l'hôte n'est indisponible que quelques secondes ;
3. Redémarrer les conteneurs immédiatement ;
4. Exporter tranquillement les données depuis le snapshot (qui, lui, ne bouge plus) vers le NAS, sans contrainte de temps.

L'indisponibilité réelle des services se limite donc au temps du snapshot, pas à la durée du transfert vers le NAS qui peut prendre plusieurs minutes selon le volume de données.

3. Script d'automatisation

Exemple de script qui orchestre l'arrêt, le snapshot Btrfs, le redémarrage, puis l'export vers un partage NAS :

#!/bin/bash
# Sauvegarde cohérente des volumes Docker via snapshot Btrfs,
# puis export vers un partage NAS consommé par Hyperbackup.
set -euo pipefail

COMPOSE_DIR="/srv/docker/monapp"
VOLUME_SUBVOL="/mnt/data/docker-volumes"
SNAP_DIR="/mnt/data/.snapshots"
EXPORT_DIR="/mnt/nas/backups/docker/monapp"
DATE=$(date +%Y%m%d-%H%M)
SNAP_PATH="${SNAP_DIR}/monapp-${DATE}"

# 1. Arrêt propre des conteneurs (le temps d'indisponibilité réel)
docker compose -f "${COMPOSE_DIR}/docker-compose.yml" stop

# 2. Snapshot atomique du volume (quasi instantané)
btrfs subvolume snapshot -r "${VOLUME_SUBVOL}" "${SNAP_PATH}"

# 3. Redémarrage immédiat des services
docker compose -f "${COMPOSE_DIR}/docker-compose.yml" start

# 4. Export du snapshot vers le NAS, sans contrainte de temps
mkdir -p "${EXPORT_DIR}"
tar -czf "${EXPORT_DIR}/monapp-${DATE}.tar.gz" -C "${SNAP_PATH}" .

# 5. Nettoyage : suppression du snapshot local et purge des archives de plus de 30 jours
btrfs subvolume delete "${SNAP_PATH}"
find "${EXPORT_DIR}" -name '*.tar.gz' -mtime +30 -delete

Ce script est ensuite planifié via cron sur l'hôte Docker, à une fréquence adaptée à la criticité de l'application (nocturne pour la plupart des services internes).

4. L'intégration avec Hyperbackup

Le script ci-dessus dépose des archives datées dans un dossier du NAS Synology — jusque-là, rien de plus qu'un simple export. C'est Hyperbackup, côté NAS, qui prend le relais pour la partie qu'il fait mieux que n'importe quel script maison : il traite ce dossier comme une source classique et applique dessus sa propre politique de rétention (versions horodatées, rotation, purge progressive), sa déduplication de blocs, son chiffrement, et éventuellement une réplication vers un second NAS ou un stockage cloud. Le script se contente donc de produire des archives propres et datées ; Hyperbackup gère tout le cycle de vie de la sauvegarde à partir de là.

5. Le cas particulier des bases de données

Un snapshot filesystem capture les fichiers tels qu'ils sont sur le disque à l'instant T, ce qui est suffisant pour la plupart des applications stateless ou des fichiers de configuration. Une base de données relationnelle (PostgreSQL, MySQL/MariaDB) reste néanmoins un cas particulier : même arrêtée proprement, un dump applicatif reste préférable au fichier brut, car il garantit un format cohérent et portable, indépendant de la version exacte du moteur de stockage.

6. Tester la restauration

Comme pour toute sauvegarde, l'archive n'a de valeur que si elle se restaure. Prévoyez de temps en temps de reconstruire un conteneur à partir d'une archive récupérée sur le NAS (ou d'une version antérieure remontée via Hyperbackup) sur un hôte de test, pour vérifier que le volume restauré redémarre correctement l'application.

Conclusion

Le trio snapshot atomique + script d'export + Hyperbackup couvre l'essentiel : cohérence des données au moment de la copie, automatisation sans intervention manuelle, et gestion de la rétention déléguée à un outil conçu pour ça plutôt que réinventée dans un script. C'est une base solide, à compléter par des dumps applicatifs pour tout ce qui touche aux bases de données. Si vous voulez sécuriser la sauvegarde de votre infrastructure Docker, n'hésitez pas à me contacter.