## Introduction

Perdre des données d'un conteneur Docker est une erreur courante et douloureuse. Sans une stratégie de sauvegarde appropriée, une simple suppression de conteneur ou une mauvaise configuration de volume peut supprimer définitivement des données applicatives critiques. Ce guide propose une approche pratique, étape par étape, pour sauvegarder et restaurer des volumes Docker, en couvrant à la fois les volumes nommés et les montages de liaison (bind mounts). Vous apprendrez à inspecter votre environnement, à créer des sauvegardes fiables, à restaurer les données lorsque nécessaire et à valider que vos sauvegardes fonctionnent réellement. L'accent est mis sur la sécurité opérationnelle : comprendre l'emplacement de vos données, tester vos sauvegardes et disposer d'un plan de récupération clair. À la fin, vous serez en mesure de protéger vos applications conteneurisées contre la perte de données et de récupérer rapidement en cas de panne.

## Inventaire de version et d'environnement

Avant de sauvegarder un volume Docker, vous devez savoir exactement avec quoi vous travaillez. Commencez par recueillir des informations sur votre installation Docker, les conteneurs en cours d'exécution et les volumes qu'ils utilisent. Cette étape garantit que vous sauvegardez les bonnes données et comprenez où elles se trouvent.

### Vérifier la version et la configuration de Docker

Exécutez `docker version` pour voir les versions du client et du serveur. Par exemple :

```
Client: Docker Engine - Community
 Version:           24.0.5
 API version:       1.43
 Go version:        go1.20.6
 Git commit:        24.0.5-0ubuntu1~22.04.1
 Built:             Thu Aug 24 09:32:40 2023
 OS/Arch:           linux/amd64
 Context:           default

Server: Docker Engine - Community
 Engine:
  Version:          24.0.5
  API version:      1.43 (minimum version 1.12)
  Go version:       go1.20.6
  Git commit:       24.0.5-0ubuntu1~22.04.1
  Built:            Thu Aug 24 09:32:40 2023
  OS/Arch:          linux/amd64
  Experimental:     false
```

Si vous utilisez Docker Compose, vérifiez `docker compose version` (par exemple, `Docker Compose version v2.20.2`). Connaître ces versions aide lors du dépannage des outils de sauvegarde ou des différences de syntaxe.

### Lister les conteneurs en cours d'exécution et leur état

Utilisez `docker ps` pour voir les conteneurs actifs, y compris les noms, l'état et les ports :

```
docker ps --format "table {{.Names}}\t{{.Status}}\t{{.Ports}}"
```

Exemple de sortie :

```
NAMES     STATUS         PORTS
web       Up 2 hours     0.0.0.0:80->80/tcp
db        Up 2 hours     0.0.0.0:5432->5432/tcp
```

Notez tous les conteneurs qui redémarrent ou sont arrêtés, car ils peuvent contenir des données nécessitant une attention.

### Inspecter les montages des conteneurs

Pour voir quels volumes ou montages de liaison un conteneur utilise, exécutez `docker inspect` avec un filtre :

```
docker inspect --format '{{ range .Mounts }}{{ .Type }} {{ .Name }} {{ .Source }} -> {{ .Destination }}{{ end }}' db
```

Pour un conteneur nommé `db`, cela peut afficher :

```
volume postgres_data /var/lib/docker/volumes/postgres_data/_data -> /var/lib/postgresql/data
```

Cela montre un volume nommé `postgres_data` monté sur `/var/lib/postgresql/data`.

### Comprendre les volumes nommés et les montages de liaison

- **Volumes nommés** : ils sont gérés par Docker et stockés sous `/var/lib/docker/volumes/` par défaut. Ils sont portables entre conteneurs et recommandés pour les données persistantes.
- **Montages de liaison** : ils lient directement un répertoire hôte dans le conteneur, par exemple `./data:/var/lib/app`. Ils sont utiles pour le développement mais peuvent causer des problèmes de permissions et ne sont pas aussi faciles à gérer que les volumes nommés.

Lors de la sauvegarde, la méthode diffère légèrement : pour les volumes nommés, vous pouvez utiliser l'API de volume Docker ; pour les montages de liaison, vous sauvegardez directement le répertoire hôte.

### Test de redémarrage pour confirmer la persistance

Avant de créer des sauvegardes, assurez-vous que vos données persistent réellement lors des redémarrages du conteneur. Exécutez :

```
docker stop db
docker rm db
docker run -d --name db -v postgres_data:/var/lib/postgresql/data postgres:15
```

Vérifiez ensuite que les données sont toujours présentes. Si elles ont disparu, le conteneur écrivait dans son système de fichiers éphémère au lieu du volume. Corrigez cela avant de sauvegarder.

## Chemin de configuration sécurisé

Une configuration de sauvegarde sécurisée minimise les risques et garantit que vous pouvez restaurer les données sans surprises. Cela implique d'utiliser des montages de volume appropriés, de définir correctement les permissions des fichiers et d'éviter les pièges courants comme la liaison vers le chemin interne d'un conteneur au lieu d'un volume.

### Utiliser des volumes nommés pour les données de production

Pour tout service avec état (base de données, stockage de fichiers, files de messages), définissez un volume nommé dans votre fichier Docker Compose ou votre commande `docker run`. Exemple de `docker-compose.yml` :

```yaml
version: '3.8'
services:
  db:
    image: postgres:15
    volumes:
      - postgres_data:/var/lib/postgresql/data
volumes:
  postgres_data:
```

Cela indique clairement que `postgres_data` est persistant et peut être sauvegardé indépendamment.

### Éviter l'écrasement accidentel des chemins hôtes

Lorsque vous utilisez des montages de liaison, soyez prudent avec les chemins relatifs. Par exemple, `./data:/var/lib/app` monte le répertoire hôte `./data` relatif au fichier Compose. Si vous exécutez le même fichier Compose depuis un autre répertoire, le chemin des données change. Utilisez toujours des chemins absolus pour les données critiques ou préférez les volumes nommés.

### Définir des permissions de fichiers correctes

Certains conteneurs s'exécutent en tant qu'utilisateur non root et peuvent ne pas écrire sur un montage de liaison si les permissions sont incorrectes. Vérifiez l'utilisateur du conteneur avec `docker exec <conteneur> whoami` et ajustez la propriété du répertoire hôte en conséquence. Pour les volumes nommés, Docker gère les permissions en fonction de l'utilisateur par défaut de l'image.

### Garder les secrets hors des lignes de commande

N'intégrez pas de mots de passe ou de clés API dans les commandes `docker run` ou les fichiers d'environnement qui pourraient être capturés dans l'historique du shell ou les journaux. Utilisez les secrets Docker ou un outil de gestion des secrets.

## Stratégies de sauvegarde et exemples pratiques

Maintenant que votre environnement est compris et configuré correctement, vous pouvez créer des sauvegardes. Il existe deux approches principales : utiliser un conteneur temporaire avec tar (fonctionne pour les volumes nommés et les montages de liaison) ou utiliser les fonctionnalités de snapshot de volume de Docker (disponibles dans les versions récentes avec certains plugins).

### Sauvegarder un volume nommé avec un conteneur temporaire

La méthode la plus portable consiste à démarrer un conteneur temporaire qui monte le volume et crée une archive. Par exemple, pour sauvegarder le volume `postgres_data` :

```bash
docker run --rm -v postgres_data:/data -v $(pwd):/backup alpine tar czf /backup/postgres_data_backup.tar.gz -C /data .
```

Explication :
- `--rm` supprime le conteneur après sa sortie.
- `-v postgres_data:/data` monte le volume sur `/data` dans le conteneur.
- `-v $(pwd):/backup` monte le répertoire de travail courant sur `/backup` pour que l'archive se retrouve sur l'hôte.
- `alpine` est une image légère avec `tar`.
- `tar czf /backup/postgres_data_backup.tar.gz -C /data .` crée une archive compressée du contenu du volume.

Après exécution, vous trouverez `postgres_data_backup.tar.gz` dans votre répertoire courant.

### Sauvegarder un montage de liaison

Si vous utilisez un montage de liaison, vous pouvez simplement compresser le répertoire hôte. Par exemple, si votre montage de liaison est `/opt/app/data`, exécutez :

```bash
tar czf /backup/app_data_backup.tar.gz -C /opt/app/data .
```

Cela évite la surcharge d'un conteneur temporaire.

### Sauvegarder tous les volumes en une fois (exemple de script)

Pour plusieurs volumes, vous pouvez les parcourir en boucle. Enregistrez ce script sous `backup_volumes.sh` :

```bash
#!/bin/bash
BACKUP_DIR="/backups/docker-volumes"
DATE=$(date +%Y%m%d_%H%M%S)
mkdir -p "$BACKUP_DIR"

for VOLUME in $(docker volume ls -q); do
  echo "Sauvegarde du volume : $VOLUME"
  docker run --rm -v "$VOLUME":/data -v "$BACKUP_DIR":/backup alpine tar czf "/backup/${VOLUME}_${DATE}.tar.gz" -C /data .
done
```

Rendez-le exécutable avec `chmod +x backup_volumes.sh` et exécutez-le. Cela crée des archives horodatées pour chaque volume. Envisagez d'ajouter une politique de rétention pour supprimer automatiquement les anciennes sauvegardes.

### Utiliser des outils de sauvegarde de volume Docker

Il existe des outils tiers comme `docker-volume-backup` qui offrent plus de fonctionnalités (chiffrement, compression, stockage distant). Ils peuvent être exécutés en tant que conteneurs sidecar dans votre configuration Compose. Étudiez s'ils correspondent à votre flux de travail.

## Procédures de restauration

Une sauvegarde est inutile si vous ne pouvez pas la restaurer. Testez votre processus de restauration dans un environnement sûr avant d'en avoir besoin en cas d'urgence.

### Restaurer un volume nommé depuis une archive

Pour restaurer un volume nommé à partir d'une archive tar.gz, utilisez un conteneur temporaire :

```bash
docker run --rm -v postgres_data:/data -v $(pwd):/backup alpine sh -c "tar xzf /backup/postgres_data_backup.tar.gz -C /data"
```

Cela monte le volume et extrait l'archive. Assurez-vous que le volume existe et est vide (ou écrasez-le si nécessaire). Si le volume n'existe pas, créez-le d'abord avec `docker volume create postgres_data`.

### Restaurer vers un nouveau volume pour test

Avant d'écraser les données de production, restaurez vers un nouveau volume et vérifiez le contenu :

```bash
docker volume create postgres_data_test
docker run --rm -v postgres_data_test:/data -v $(pwd):/backup alpine sh -c "tar xzf /backup/postgres_data_backup.tar.gz -C /data"
```

Montez ensuite ce volume sur un conteneur de test et vérifiez l'application.

### Restaurer un montage de liaison

Pour les montages de liaison, extrayez simplement l'archive vers le répertoire hôte :

```bash
tar xzf /backup/app_data_backup.tar.gz -C /opt/app/data
```

Assurez-vous que le répertoire cible a les permissions correctes.

## Vérification et diagnostics

Après une sauvegarde ou une restauration, vérifiez que les données sont intactes et que l'application fonctionne correctement. Ne supposez pas le succès en vous basant uniquement sur l'absence d'erreurs lors de l'opération tar.

### Vérifier l'intégrité de l'archive

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

```bash
tar tzf postgres_data_backup.tar.gz | head -20
```

Comparez le nombre de fichiers ou les tailles avec le volume d'origine. Vous pouvez utiliser `docker run --rm -v postgres_data:/data alpine find /data -type f | wc -l` pour compter les fichiers dans le volume et comparer avec le nombre de fichiers de l'archive.

### Tester la restauration sur un environnement de staging

Dans la mesure du possible, restaurez vers un volume de staging et exécutez votre application dessus. Effectuez des tests de fumée : connectez-vous à la base de données, interrogez des données d'exemple ou vérifiez l'intégrité des fichiers. Cela permet de détecter des problèmes comme des sauvegardes incomplètes ou des problèmes de permissions.

### Vérifier les journaux de l'application après restauration

Après avoir démarré un conteneur avec le volume restauré, surveillez les journaux pour détecter les erreurs :

```bash
docker logs db --tail 100
```

Recherchez des messages indiquant des fichiers manquants, des permissions refusées ou une corruption.

### Utiliser des sommes de contrôle pour les données importantes

Pour les fichiers critiques, calculez des sommes de contrôle avant et après la sauvegarde pour garantir l'intégrité :

```bash
# Avant la sauvegarde (dans le conteneur ou le volume)
docker run --rm -v postgres_data:/data alpine sha256sum /data/important.txt
# Après restauration sur le volume restauré
docker run --rm -v postgres_data_restored:/data alpine sha256sum /data/important.txt
```

Les hachages doivent correspondre.

## Modes de défaillance et récupération

Même avec des sauvegardes, les choses peuvent mal tourner. Connaître les modes de défaillance courants vous aide à vous préparer et à récupérer rapidement.

### Volume mal monté

**Symptôme** : Le conteneur démarre mais les données sont manquantes ou des erreurs d'application indiquent le mauvais répertoire.

**Cause** : Faute de frappe dans le nom du volume, liaison vers un chemin de conteneur qui n'est pas l'emplacement réel des données, ou utilisation d'un chemin relatif qui a été résolu différemment.

**Récupération** : Vérifiez les montages avec `docker inspect`, corrigez la spécification du volume et redémarrez le conteneur. Testez avec un fichier factice pour confirmer que le montage correspond.

### La sauvegarde contient des données vides

**Symptôme** : La taille de l'archive de sauvegarde est très petite (par exemple, 20 octets) ou ne contient aucun fichier.

**Cause** : Le volume était vide ou la commande tar a archivé le mauvais répertoire (par exemple, avoir oublié `-C /data`).

**Récupération** : Refaites la sauvegarde avec la commande correcte. Listez toujours le contenu de l'archive et comparez le nombre de fichiers avant de faire confiance à la sauvegarde.

### La restauration écrase des données existantes

**Symptôme** : Après la restauration, les modifications récentes sont perdues car l'archive était ancienne ou l'extraction a écrasé des fichiers plus récents.

**Cause** : Restauration vers un volume qui contenait déjà des données sans les sauvegarder d'abord.

**Récupération** : Sauvegardez toujours le volume actuel avant de restaurer, même si vous pensez qu'il est corrompu. Conservez des sauvegardes versionnées.

### Permission refusée après restauration d'un montage de liaison

**Symptôme** : L'application ne peut pas écrire dans les fichiers restaurés.

**Cause** : La propriété des fichiers a changé pendant le processus de sauvegarde/restauration (par exemple, exécuter tar en tant que root change la propriété en root).

**Récupération** : Ajustez la propriété et les permissions dans le conteneur ou sur l'hôte. Par exemple, si le conteneur s'exécute avec l'uid 1000, exécutez `chown -R 1000:1000 /opt/app/data` sur l'hôte avant de démarrer le conteneur.

### Sauvegarde interrompue ou incohérente (base de données)

**Symptôme** : La base de données ne démarre pas après la restauration car la sauvegarde a été prise alors que la base de données était en cours d'exécution sans une mise en veille appropriée.

**Cause** : Les bases de données comme PostgreSQL ou MySQL nécessitent des instantanés cohérents ; simplement compresser le répertoire de données pendant que la base de données est en cours d'exécution peut produire une sauvegarde corrompue.

**Récupération** : Utilisez des outils de sauvegarde spécifiques à la base de données (par exemple, `pg_dump` pour PostgreSQL, `mysqldump` pour MySQL) au lieu d'une copie brute du volume, ou arrêtez le conteneur de la base de données avant de sauvegarder le volume.

### Épuisement de l'espace disque pendant la sauvegarde

**Symptôme** : La sauvegarde échoue avec « no space left on device ».

**Cause** : Le répertoire de sauvegarde est sur un petit disque ou trop d'anciennes sauvegardes subsistent.

**Récupération** : Nettoyez les anciennes sauvegardes, déplacez l'emplacement de sauvegarde vers un volume plus grand ou compressez plus agressivement.

## Liste de contrôle opérationnelle

Utilisez cette liste de contrôle avant et après les opérations de sauvegarde pour garantir cohérence et fiabilité.

| Élément | Responsable | Fréquence | Détails |
|---------|-------------|-----------|---------|
| Vérifier les montages de volume corrects | Ingénieur DevOps : Priya Shah | Avant chaque sauvegarde | Exécuter `docker inspect` et comparer aux montages documentés. |
| Vérifier l'espace disque pour les sauvegardes | Administrateur système : Tom Chen | Hebdomadaire | S'assurer que le répertoire de sauvegarde a suffisamment d'espace libre (au moins 2 fois la taille du volume). |
| Effectuer une sauvegarde | Script d'automatisation | Quotidien (cron) | Exécuter `backup_volumes.sh` à 2 h du matin heure du serveur. |
| Tester la restauration sur staging | Responsable QA : Maria Garcia | Mensuel | Restaurer la dernière sauvegarde sur un volume de staging et exécuter des tests de fumée. |
| Vérifier l'intégrité des sauvegardes | Ingénieur DevOps : Priya Shah | Hebdomadaire | Vérifier le contenu de l'archive, le nombre de fichiers et les sommes de contrôle sur un échantillon. |
| Rotation des anciennes sauvegardes | Script d'automatisation | Quotidien | Supprimer les sauvegardes de plus de 30 jours sauf si marquées permanentes. |
| Examiner les journaux de sauvegarde | Ingénieur d'astreinte | Quotidien | Rechercher des erreurs dans la sortie du script de sauvegarde. |
| Mettre à jour la documentation de sauvegarde | Rédacteur technique : John Lee | Trimestriel | S'assurer que les commandes et procédures correspondent à l'environnement actuel. |

## Pièges courants et comment les éviter

1. **Supposer que les montages de liaison sont sauvegardés par Docker** : Docker ne sauvegarde pas automatiquement les montages de liaison. Si vous comptez sur la gestion des volumes de Docker, les données des montages de liaison peuvent être perdues lorsque le répertoire hôte est supprimé. Évitez cela en utilisant des volumes nommés pour les données critiques, et si vous devez utiliser des montages de liaison, incluez le répertoire hôte dans votre solution de sauvegarde au niveau de l'hôte.

2. **Ne pas tester les restaurations** : De nombreuses équipes créent des sauvegardes mais ne vérifient jamais qu'elles peuvent restaurer. Une sauvegarde qui ne peut pas être restaurée est sans valeur. Évitez cela en planifiant des tests de restauration réguliers (par exemple, mensuels) et en documentant le processus.

3. **Utiliser des copies brutes de volume pour les bases de données** : Comme mentionné, copier un volume de base de données en direct peut entraîner une corruption. Évitez cela en utilisant des outils de vidage natifs de la base de données ou en arrêtant la base de données avant de sauvegarder.

4. **Ignorer les permissions de fichiers** : Après la restauration, les erreurs de permission peuvent provoquer des défaillances d'application. Évitez cela en documentant la propriété attendue et en la définissant correctement après la restauration, ou utilisez des outils qui préservent les permissions (par exemple, tar avec l'option `-p`).

5. **Stocker les sauvegardes sur le même disque que les données** : Si le disque tombe en panne, vous perdez à la fois les données et la sauvegarde. Évitez cela en stockant les sauvegardes sur un disque physique séparé, un stockage réseau ou un stockage d'objets cloud.

6. **Ne pas automatiser les sauvegardes** : Les sauvegardes manuelles sont souvent oubliées. Évitez cela en configurant des tâches cron ou des pipelines CI/CD pour exécuter les sauvegardes selon un calendrier, et alertez en cas d'échec.

## Conclusion

Les volumes Docker sont le principal moyen de persister les données, mais ils nécessitent des stratégies délibérées de sauvegarde et de restauration. En suivant les pratiques de ce guide — comprendre votre environnement, configurer correctement les volumes, créer et tester des sauvegardes, et se préparer aux défaillances — vous pouvez protéger vos données et minimiser les temps d'arrêt. Commencez par une sauvegarde simple à l'aide d'un conteneur temporaire, puis passez à des sauvegardes automatisées et versionnées avec des tests de restauration planifiés. N'oubliez pas : une sauvegarde ne vaut que par sa vérification de restauration. Agissez dès aujourd'hui pour mettre en œuvre ces étapes et garantir la sécurité de vos données Docker. Comme prochaine étape, choisissez l'un de vos volumes critiques et créez une sauvegarde, puis entraînez-vous à la restaurer vers un nouveau volume pour confirmer que le processus fonctionne. Documentez ensuite la procédure et mettez en place l'automatisation pour protéger vos données en continu.