Sauvegarder une application Docker Compose et tester la restauration

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.

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.

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.

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.

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.

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.

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.