Dans cet article
Un snapshot remet une machine en route. Cette procédure conserve aussi la configuration, les données et le dump nécessaires pour remettre l'application en route.
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
.envde 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.
cd /srv/YOUR_APP
sudo docker compose config --services
sudo docker compose config
sudo docker volume ls
sudo docker compose ps
Vérifier le périmètre de capture du script figé
Avant d’acheter du stockage, de planifier une tâche ou de suspendre les écritures, associez chaque élément de l’inventaire de reprise à un artefact précis capturé ou à une procédure de récupération distincte déjà testée. Le script de sauvegarde figé accepte seulement un dossier contenant compose.yml ou docker-compose.yml. Sa liste de configuration se limite exactement à compose.yml, docker-compose.yml, .env et Caddyfile, lorsqu’ils existent. Il archive uniquement les volumes nommés dans VOLUME_NAMES, plus le dump PostgreSQL configuré facultatif.
Un dossier contenant seulement compose.yaml ou docker-compose.yaml échoue au contrôle du nom de fichier. Les données des montages bind, les overrides/includes, les fichiers env_file supplémentaires et les secrets/configurations stockés dans des fichiers ne sont pas capturés automatiquement. Ces dépendances peuvent manquer même si la commande annonce un envoi réussi. La configuration Compose résolue aide à les repérer ; elle n’étend pas la capture du script. Gardez cette sortie privée, car elle peut contenir des secrets.
Arrêtez cette procédure si la structure n’est pas prise en charge ou si un élément nécessaire n’a pas de méthode de récupération. Ne renommez pas aveuglément les fichiers Compose de production et ne retirez pas les overrides pour passer le contrôle. Faites d’abord relire et tester une procédure adaptée à cette structure, avant toute maintenance. Le compagnon n’a pas été modifié pour gérer ces cas ; son exemple simple à volumes nommés ne certifie pas la récupération d’autres applications.
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.
Sauvegarder un serveur Minecraft vers Spaces privé · Exécuter n8n privé et tester la restauration
Suivez les instructions officielles sur les droits des clés Spaces, le versionnement et les règles de cycle de vie. Ne conservez pas la clé de configuration sur le serveur qui exécute les sauvegardes.
Exécuter une première sauvegarde avant de la planifier
Le script compagnon crée un lot horodaté. Il arrête les services applicatifs actifs avant le dump PostgreSQL et la copie des volumes hors base. PostgreSQL reste disponible pour le dump. Le script relance seulement les services arrêtés, puis chiffre le lot. Suspendez aussi les écritures externes pendant toute la capture.
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.
Avant ces commandes, installez AWS CLI et age sur le serveur. Docker et Compose doivent déjà exécuter votre application. Générez l'identité age sur votre poste d'administration, conservez la clé privée hors du serveur et renseignez seulement son destinataire public dans AGE_RECIPIENT.
Pour la première répétition, utilisez l’exemple fixture/ du dépôt sur un serveur jetable. Il crée un enregistrement de base pointant vers uploads/record-42.txt dans un volume nommé. Son README fournit la correspondance exacte et le contrôle de reprise.
Installez AWS CLI v2 et age selon son guide officiel. Notez aws --version, age --version et docker compose version dans le compte rendu : il s’agit de prérequis, pas de versions testées par cet article. PostgreSQL explique la cohérence interne d’un export logique ; les écritures dans les fichiers applicatifs doivent rester suspendues pendant toute la capture.
git clone https://github.com/TylorMayfield/docker-compose-spaces-recovery.git
cd docker-compose-spaces-recovery
git checkout 08fcc40647eef74eb7015fb66c00a96386795dc0
sudo install -m 600 .env.example /etc/compose-recovery.env
sudo nano /etc/compose-recovery.env
# Définissez APP_DIR, BUCKET, REGION, VOLUME_NAMES, AGE_RECIPIENT et les réglages PostgreSQL facultatifs.
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.
sudo bash -c 'set -a; . /etc/compose-recovery.env; set +a; export AWS_DEFAULT_REGION=us-east-1; aws s3 ls "s3://$BUCKET/$PREFIX/" --endpoint-url "https://$REGION.digitaloceanspaces.com"'
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.
git clone https://github.com/TylorMayfield/docker-compose-spaces-recovery.git
cd docker-compose-spaces-recovery
git checkout 08fcc40647eef74eb7015fb66c00a96386795dc0
sudo install -m 600 .env.example /etc/compose-recovery-restore.env
sudo nano /etc/compose-recovery-restore.env
# Définissez RESTORE_ENV=test, la clé lecture seule, un TIMESTAMP et les quatre valeurs PostgreSQL lorsque postgres.dump existe.
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.
Surveiller un site avec Uptime Kuma · Auto-héberger un serveur de chat Stoat privé
Le jeu de test figé n’est validé que si la ligne restaurée 42 désigne toujours uploads/record-42.txt et si ce fichier contient record-42. Notez l’horodatage, le SHA du dépôt, les versions de base et d’image, les deux résultats et la durée de restauration. C’est une procédure de validation, pas le résultat d’une restauration réelle.
Questions fréquentes
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.