Un snapshot de Droplet suffit-il pour une application Docker Compose ?

Un snapshot aide à récupérer une machine entière. Gardez aussi une sauvegarde applicative portable avec fichiers Compose, données persistantes et dump de base, puis testez-la sur un autre serveur.

Puis-je archiver un volume PostgreSQL actif avec tar ?

N’en dépendez pas pour PostgreSQL. Utilisez pg_dump ou une autre méthode prise en charge par la base, puis restaurez-la dans une base neuve pendant le test.

Pourquoi séparer les clés de sauvegarde et de restauration ?

Le serveur de production doit écrire. Le serveur de test temporaire doit seulement lire un lot. Des clés limitées distinctes réduisent ce que chacune peut faire si elle fuit.

À quelle fréquence tester une restauration ?

Testez après la première sauvegarde, avant des changements majeurs et selon le risque du service. Notez le résultat pour ne pas dépendre de souvenirs pendant une panne.

← Tous les guidesExploitation de site

Sauvegarder une application Docker Compose et tester la restauration

2 septembre 2026

Sauvegardez la configuration Docker Compose, les volumes nommés et PostgreSQL dans un stockage privé, puis prouvez la restauration sur un serveur isolé.

Dépôt GitHub compagnonScripts compagnons de reprise Docker ComposeTylorMayfield/docker-compose-spaces-recoveryVoir sur GitHub

Temps à prévoir: Prévoyez 90 minutes pour la première sauvegarde et un test de restauration séparé.
Niveau conseillé: Être à l’aise avec SSH, Docker Compose et l’identification des données de l’application.
Coût de départ: Le serveur, le stockage de sauvegarde, les snapshots et le serveur de test ont des coûts courants distincts. Consultez chaque écran de création.
À préparer: Une application Compose dont vous pouvez identifier les fichiers et volumes nommés.
Un compartiment privé et des clés limitées distinctes pour sauvegarde et restauration.
Un serveur, un nom d’hôte et une règle de pare-feu hors production pour le test.

Le chemin vers le résultat

Inventorier les fichiers Compose, volumes et base.
Chiffrer et envoyer un lot daté vers le stockage privé.
Restaurer un lot sur un serveur isolé et noter le résultat.

Application Compose
Le serveur de production contient le fichier Compose, le fichier d’environnement protégé, les volumes nommés et parfois un service de base distinct.
Frontière: Serveur de production
Lot chiffré
La tâche archive la configuration et les volumes, crée un dump PostgreSQL lorsqu’il est utilisé, puis chiffre les fichiers avant l’envoi.
Frontière: Stockage objet privé
Identité de récupération
L’identité de déchiffrement reste hors du serveur applicatif et des identifiants du compartiment.
Frontière: Secret séparé
Serveur de test
Un serveur neuf utilise un nom de test, un pare-feu restreint et un trafic sortant bloqué avant le démarrage.
Frontière: Aucun trafic de production

Point d’attention: Un envoi réussi prouve seulement qu’un fichier a atteint le stockage. Le test prouve si les fichiers démarrent réellement l’application.

Décider ce qui doit revenir

Une application Docker Compose est récupérable seulement si vous pouvez reconstruire sa configuration, restaurer ses données et la démarrer sans deviner quel secret ou quelle version elle utilisait. Une sauvegarde ou un snapshot de Droplet reste utile pour un problème de machine. Il ne remplace pas un test de restauration de l’application.

Commencez par une seule application. Notez son dossier Compose, son fichier `.env`, ses volumes nommés, ses montages, ses tags d’image, son service de base, son nom public et un contrôle inoffensif. Si vous ne pouvez pas les nommer, n’automatisez pas encore la sauvegarde.

Copiez la configuration seulement depuis un dossier protégé. Ne commitez jamais un `.env` de production.
Utilisez un dump logique PostgreSQL pour les données PostgreSQL. N’archivez pas ses fichiers actifs avec tar.
Gardez l’identité de déchiffrement hors du serveur applicatif et du compartiment.

Tenir un inventaire de reprise court

Exécutez ces commandes en lecture seule dans le dossier de l’application. Elles montrent les services, la configuration Compose résolue et les volumes Docker disponibles. Notez les volumes qui comptent. Un volume appelé `postgres_data` est fréquent, pas obligatoire.

Modifier d’abordRemplacez chaque valeur surlignée avant d’exécuter la commande.

cd /srv/YOUR_APP
sudo docker compose config --services
sudo docker compose config
sudo docker volume ls
sudo docker compose ps

Remplacez avant l’utilisation : YOUR_APP

Créer un stockage privé et des clés séparées

Créez un compartiment Spaces privé pour ce lot de reprise. Activez le versioning et choisissez une règle de cycle de vie qui correspond à la rétention approuvée. Utilisez une clé à accès complet seulement pour configurer les règles. Donnez à la tâche planifiée une clé limitée à ce compartiment. Créez une deuxième clé limitée en lecture pour le test.

Gardez le compartiment privé. N’ajoutez ni CDN, ni politique publique, ni listing public.

Vérifier la première réponse

Résultat attendu: Le serveur de test déchiffre un lot complet, démarre l’application récupérée sous un nom de test et expose une donnée connue en lecture seule sans contacter la production.
Arrêter si: Arrêtez si la cible est un serveur de production, si le lot manque son manifeste ou a des horodatages différents, si le service récupéré peut envoyer du trafic sortant, si un nom de production reste présent ou si un secret apparaît dans la sortie.
Étape suivante: Consignez l’horodatage, la durée et le résultat. Retirez les données récupérées du serveur de test et examinez chaque changement manuel avant de planifier la tâche.

Exécuter une première sauvegarde avant de la planifier

Le script compagnon crée un lot horodaté. Il produit un dump PostgreSQL au format personnalisé via le conteneur de base quand vous le configurez. Il arrête ensuite la pile Compose pendant l’archive des volumes sélectionnés hors base, puis chiffre le lot avant l’envoi.

Cette courte pause est volontaire. Si l’application ne peut pas la supporter, utilisez la méthode de sauvegarde en ligne documentée par son éditeur.

Emplacement indiqué par étape5 étapes

Avant de continuer : Exécutez la première sauvegarde manuellement et vérifiez son manifeste avant de la planifier. Gardez le fichier de configuration hors du dépôt cloné.

git clone https://github.com/TylorMayfield/docker-compose-spaces-recovery.git

Ouvrir le projetDroplet connecté
```
cd docker-compose-spaces-recovery
```
Créer le fichier de configuration protégéDroplet connecté
```
sudo install -m 600 .env.example /etc/compose-recovery.env
```
Définir les valeurs de sauvegardeÉditeur de fichiers du serveur
```
sudo nano /etc/compose-recovery.env
```

sudo ./scripts/backup-compose-app.sh /etc/compose-recovery.env

Vérifier le lot avant de lui faire confiance

La commande doit laisser un manifeste et les fichiers chiffrés sous le même horodatage. Listez le préfixe distant après la première exécution et notez l’horodatage. Un manifeste manquant, une archive vide ou un dump sans configuration correspondante signifie que la sauvegarde a échoué.

Planifiez seulement la commande déjà inspectée. Envoyez stderr vers l’alerte que l’équipe consulte.

set -a
. /etc/compose-recovery.env
set +a
aws s3 ls "s3://$BUCKET/$PREFIX/" --endpoint-url "https://$REGION.digitaloceanspaces.com" | tail -8

Restaurer sur un autre serveur

Utilisez un Droplet Linux neuf, un nom de test et un Cloud Firewall qui limite HTTPS à l’administrateur de récupération. Bloquez le trafic sortant avant le démarrage. Cela évite l’envoi de messages, de paiements ou de callbacks depuis un état récupéré.

Téléchargez un lot complet et son manifeste correspondant avec la clé en lecture seule. Déchiffrez-le seulement sur le serveur de test. Le compagnon crée de nouveaux volumes Docker avec un préfixe de récupération et restaure les archives sélectionnées. Si le lot contient PostgreSQL, démarrez d’abord un conteneur neuf et une base de test vide. Dans le fichier de restauration réservé à root, renseignez le conteneur, la base, l’utilisateur et son mot de passe : le script transmet ce mot de passe seulement au processus de restauration. La commande applique les données uniquement dans ces nouveaux volumes et cette base de test, jamais en production. Remplacez le nom de production par le nom de test avant le démarrage.

Emplacement indiqué par étape6 étapes

Avant de continuer : La commande d’application écrit les données récupérées dans de nouveaux volumes de reprise et une base de test. Exécutez-la seulement sur le serveur de test isolé après avoir bloqué le trafic sortant et confirmé RESTORE_ENV=test.

git clone https://github.com/TylorMayfield/docker-compose-spaces-recovery.git

Ouvrir le projetMachine de test isolée
```
cd docker-compose-spaces-recovery
```
Créer la configuration de restaurationMachine de test isolée
```
sudo install -m 600 .env.example /etc/compose-recovery-restore.env
```
Définir les valeurs de restauration de testÉditeur de fichiers du serveur
```
sudo nano /etc/compose-recovery-restore.env
```

sudo ./scripts/restore-compose-app.sh /etc/compose-recovery-restore.env

sudo ./scripts/restore-compose-app.sh --apply /etc/compose-recovery-restore.env

Prouver l’application puis nettoyer

Une liste de conteneurs verts ne suffit pas. Connectez-vous au nom de test, trouvez une donnée connue et lancez le contrôle inoffensif choisi au début. Pour une app web, ouvrez une page en lecture seule. Pour un worker, vérifiez son démarrage avec son trafic sortant bloqué.

Notez l’horodatage, la durée et le résultat. Renouvelez tout identifiant exposé hors de son emplacement protégé. Détruisez le serveur de test ou effacez les données récupérées après le test.