Un conteneur qui plante, ça se relance. Une base de données corrompue ou un volume effacé par erreur, ça ne se rattrape pas sans une sauvegarde. Pourtant, j’ai constaté à plusieurs reprises que la plupart des installations de Docker, la sauvegarde se résume à « ça fonctionne… ça devrait aller ». Aujourd’hui, je vous propose un petit guide, générique, qui peut s’appliquer à de nombreuses distributions Linux (Ubuntu Server, Debian, Fedora…) mais aussi sur un NAS.
Sauvegarde Docker
Un environnement Docker se décompose en 3 éléments :
- La configuration : les fichiers docker-compose.yml et .env, il ne pèse que quelques octets ;
- Les données : ce sont les volumes et bind mounts contenant les bases de données, les fichiers envoyés, les configurations d’application générées à l’exécution ;
- Les images : elles se (re)téléchargent depuis un registre, peu d’intérêt les sauvegarder (sauf retour arrière instantané).
Il est important de ne pas confondre ces catégories. Il ne sert à rien de sauvegarder l’intégralité de /var/lib/docker. Ça prend de la place pour rien et complique la restauration.
Étape 1 : Configurations de côté
Chaque stack (ou Projet Docker) repose sur des fichiers texte : docker-compose.yml, .env et parfois un Dockerfile. Ces derniers décrivent comment tout est imbriqué. Regroupez-les dans un dossier (ex : docker-configs), avec un sous-dossier par stack. Ce dossier sera ensuite inclus dans la sauvegarde automatisée (voir ci-dessous), comme les volumes de données.
Vous pouvez également mettre en place un dossier sous Git, même un simple dépôt local. Cela permettra de garder un historique des modifications et de revenir en arrière en cas d’erreur de configuration.
L’objectif, c’est de pouvoir recréer une stack entière (projet docker) en question de minutes… Sur un NAS Synology, les fichiers de configuration sont généralement logés dans /volume1/docker
Étape 2 : Identifier les volumes
Passons aux données et plus précisément leurs volumes. Pour cela, vous pouvez taper :
docker volume ls
Pour chaque volume, il faut se poser la question : s’il disparait demain, est-ce que je perds quelque chose d’irremplaçable ? Je vous recommande les dossiers utilisateurs, les bases de données (voir ci-dessous) et la configuration de votre application. Il n’est pas nécessaire de sauvegarder un cache ou des fichiers temporaires.
Pour retrouver le chemin réel d’un volume, il faut taper :
docker volume inspect <nom_du_volume>
Recherchez Mountpoint qui devrait ressembler à cela : /var/lib/docker/volumes/monVolume
Étape 3 : Choisir un outil de sauvegarde de volumes
Pour un homelab, il existe plusieurs possibilités :
- docker-volume-backup : il s’agit d’une image docker qui monte vos volumes, les archives en .tar.gz puis envoie le résultat vers un stockage local, WebDAV, Dropbox, SFTP, S3… la référence ;
- Restic ou Kopia : outils de déduplication, de chiffrement et de gestion du versioning (plusieurs points de restauration dans le temps).
Pour démarrer, docker-volume-backup suffit largement. Relativement simple, vous y mettrez les informations de chaque projet Docker et bien sûr le Mountpoint correspondant pour vos données. Restic et Kopia demandent pas mal de configuration, mais ce dernier (Kopia) dispose d’une interface graphique embarqué, ce qui peut faciliter son utilisation.
Cas particulier
Y’a toujours une exception qui confirme la règle : la base de données en fonctionnement. Si techniquement la sauvegarde avec docker-volume-backup sera OK, la base données posera des soucis lors d’une restauration.
2 solutions sont possibles :
- Dump avant archivage : pg_dump pour PostgreSQL, mysqldump pour MySQL/MariaDB génère un fichier texte (exportation brute de son contenu et de sa structure), indépendant de l’état du volume, via cron ;
- Arrêt du conteneur : plus simple à automatiser, mais implique une coupure de service temporaire pour la sauvegarde.
Dans docker-volume-backup, tout conteneur portant l’étiquette docker-volume-backup.stop-during-backup=true sera arrêté avant le lancement de la sauvegarde, puis redémarré une fois celle-ci terminée.
A noter également que de nombreuses applications (Immich, Home Assistant, Jellyfin…) proposent des systèmes de sauvegarde internes.
Étape 4 : automatiser et stocker ailleurs
Une sauvegarde qui reste sur le même disque/SSD que les données originales n’est pas une sauvegarde ! C’est une copie qui disparait avec la panne de votre PC. Dans l’idéal, il faudra créer un tâche planifié (cron) qui déclenche le script ou le conteneur de sauvegarde à intervalle régulier (une fois par jour par exemple) vers un NAS ou un autre machine distante.
Étape 5 : tester vos sauvegardes
Une erreur fréquente consiste à penser qu’une sauvegarde fonctionne… sans jamais l’avoir testée. Une sauvegarde corrompue ou incomplète, ça arrive ne sert à rien. Prenez le temps de vérifier régulièrement vos fichiers. Ouvrez-les, restaurez-les, assurez-vous qu’ils sont exploitables.
Le seul à faire, c’est reconstruire une stack/projet sur une machine vierge ou une machine virtuelle, à partir du dossier de configuration et de l’archive du/des volumes pour les données. Si l’opération échoue, alors il est nécessaire de revoir votre procédure de sauvegarde. Planifiez ce genre de test au moins une fois tous les trimestres.
Synology et Docker
Synology utilise docker à travers l’outil maison Container Station. Ce dernier fait tourner les projets (stack) directement sur le NAS dans /volume1/docker avec un sous-dossier par projet. Généralement, on y retrouve la configuration et les données côte à côte. Il est important de noter que Container Manager ne propose aucune fonction de sauvegarde.
Pour cela, il est possible d’utiliser Hyper Backup par exemple… mais vous aurez le même souci au niveau de vos bases de données.
Les Snapshots Btrfs apporteront une réponse. En effet, si le snapshot est « quasi instantané » même pendant une écriture, cela sera comparable à une coupure de courant brutale. Heureusement, les systèmes de base de données (PostgreSQL, MySQL/MariaDB) sont conçus pour se remettre de ce genre de situation grâce à des mécanismes de récupération internes. Cependant, un snapshot n’est pas une sauvegarde propre de la base de données. Pour les données importantes, je vous recommande de créer un dump. A noter que la problématique (snapshot au niveau système de fichiers/hyperviseur) reste la même pour QNAP, Asustor, Proxmox, etc.
En synthèse
Vous l’aurez compris, la sauvegarde d’un environnement Docker n’est pas forcément complexe… mais il faut faire attention. Il y a 3 grandes familles de données à sauvegarder pour un projet Docker : la configuration, les données et l’image (optionnelle). L’outil docker-volume-backup sera idéal pour la majorité des utilisateurs. Cependant, il faudra être vigilant si votre projet contient une base de données. Aussi, regardez dans vos applications favorites s’il n’existe pas un système de sauvegarde intégré 😉
Les utilisateurs avancés regarderont du côté des applications Restic ou Kopia.