Comment déplacer les données des conteneurs vers un pool SSD sans casser les chemins de montage
Déplacez la source de données côté hôte vers le SSD tout en conservant inchangé le chemin de destination côté conteneur.
Une migration sûre traite la carte des montages actuelle comme un contrat d’interface. Les conteneurs, les bases de données et les applications multimédias attendent des chemins tels que /config, /data ou /media, quel que soit le disque qui les fournit. Le processus doit arrêter les écritures, monter le SSD de manière prévisible, copier les propriétaires et les métadonnées, mettre à jour uniquement la source côté hôte, vérifier le nouveau montage avant le démarrage et conserver les données d’origine jusqu’à la réussite d’un test complet de restauration.
Répertoriez chaque source actuelle et chaque destination de conteneur
Exportez le fichier Compose ou les données d’inspection des conteneurs et répertoriez chaque montage bind, volume nommé, montage tmpfs, répertoire de base de données, cache, chemin de transcodage et emplacement multimédia. Notez séparément la source côté hôte et la destination côté conteneur.
Un guide pratique de migration de volumes commence par localiser les données actuelles et arrêter les conteneurs avant de les copier vers un nouvel emplacement sur le disque. Cet inventaire évite de laisser des données de configuration sur le disque système.
Indiquez les chemins qui contiennent l’état de référence, le cache régénérable et les fichiers multimédias volumineux. Ne supposez pas qu’un dossier nommé data contient tout l’état persistant de l’application.
Montez le pool SSD de manière prévisible avant le démarrage de Docker
Créez le système de fichiers ou le pool SSD, identifiez-le à l’aide d’un UUID stable ou du nom du pool, puis montez-le sur le chemin hôte final. Vérifiez l’espace libre, les fonctionnalités attendues du système de fichiers et l’accès en écriture après un redémarrage.
Le déplacement des données Docker vers un stockage externe peut échouer lorsque le disque est absent ou monté sur un autre chemin au démarrage. Un cas récent concernant un SSD externe montre comment le déplacement du stockage Docker modifie la dépendance envers le chemin de montage cible.
Configurez l’ordre de démarrage des services ou le comportement de montage automatique afin que Docker ne crée jamais un répertoire de secours vide sur le disque système. Arrêtez la procédure si le SSD n’est pas monté exactement sur le chemin attendu.
Arrêtez les processus d’écriture et copiez les données en préservant les métadonnées
Arrêtez l’application et toutes les dépendances susceptibles d’écrire dans ses données, notamment les bases de données, les indexeurs, les téléchargeurs et les tâches en arrière-plan. Pour les bases de données, effectuez une exportation cohérente avec l’application ou un arrêt propre avant de copier les fichiers bruts.
Une discussion Synology consacrée aux conteneurs recommande de déplacer un volume géré par Docker vers un montage bind uniquement après avoir identifié les données du volume et préservé leur contenu dans la nouvelle source du montage bind.
Copiez récursivement en préservant les propriétaires, les permissions, les horodatages, les liens, les ACL et les attributs étendus lorsque le système le permet. Effectuez une comparaison à blanc ou vérifiez un échantillon par somme de contrôle après la copie et avant de modifier Compose.
Modifiez uniquement le chemin source côté hôte
Conservez la destination côté conteneur à l’identique. Par exemple, remplacez /oldpool/app:/config par /ssdpool/app:/config au lieu d’imposer à l’application un nouveau chemin interne.
Les montages bind exposent un emplacement hôte précis sur un chemin stable à l’intérieur du conteneur. Une présentation du stockage explique que cette mise en correspondance directe est utile lorsque les administrateurs ont besoin de contrôler le chemin côté hôte.
La conservation de la destination évite de casser les bases de données applicatives, les références de bibliothèque, les scripts, les permissions et les valeurs de configuration qui enregistrent le chemin côté conteneur.
Restaurez les propriétaires, les étiquettes et la cohérence de la base de données
Comparez les valeurs numériques UID et GID attendues par l’image avec les propriétaires définis sur le SSD. Restaurez également les ACL, les étiquettes SELinux, les autorisations AppArmor et les options de montage nécessaires au verrouillage ou aux fichiers mappés en mémoire.
Un guide de migration du stockage Docker sous macOS indique que le déplacement des données Docker nécessite de copier l’image de stockage complète, puis de confirmer que l’environnement d’exécution utilise le nouvel emplacement de stockage. Sur les systèmes NAS Linux, la vérification équivalente consiste à s’assurer que chaque source configurée pointe vers le SSD monté.
Démarrez uniquement la base de données et examinez les journaux de récupération avant de démarrer les applications dépendantes. Si elle signale une corruption ou des fichiers manquants, arrêtez la procédure et revenez à la copie d’origine plutôt que de laisser les applications initialiser une base de données vide.
Effectuez la bascule avec une possibilité de retour arrière et testez l’ensemble du processus
Démarrez la pile dans l’ordre des dépendances et vérifiez la configuration, les enregistrements de la base de données, les permissions, les bibliothèques multimédias, les téléversements, les téléchargements, les mises à jour et la recréation des conteneurs. Vérifiez que les nouvelles écritures sont effectuées sur le SSD et que le disque système ne continue plus de se remplir.
L’article de ZimaSpace consacré à un montage bind Docker soudainement passé en lecture seule présente le diagnostic à effectuer si le chemin migré est monté mais refuse les écritures.
Conservez les anciennes données hors ligne et intactes jusqu’à la réussite des sauvegardes et de la reconstruction d’un second conteneur depuis le chemin SSD. Ne supprimez l’ancienne source qu’après un exercice de retour arrière confirmant que vous pouvez restaurer le fichier Compose, les montages, les bases de données et l’état de l’application.
Produits recommandés
Assistance et conseils
Plus à lire
Pourquoi la restauration d’un volume Docker recrée-t-elle le contenu des fichiers, mais supprime-t-elle les attributs étendus ?
Un diagnostic de restauration de volume couvrant l’inventaire des xattr, les options de tar et de Rsync, les espaces de noms, la prise en...
Pourquoi un conteneur en cours d’exécution conserve-t-il son ancienne limite de mémoire après la modification du fichier Compose ?
Un diagnostic des limites mémoire couvrant les cgroups actifs, le redémarrage par rapport à la recréation, les champs Compose, les limites strictes et souples,...
Pourquoi le redémarrage d’un proxy inverse invalide-t-il toutes les sessions d’une application auto-hébergée ?
Un diagnostic de perte de session couvrant la portée des redémarrages, la propriété des cookies, la rotation des secrets, les sessions adossées au cache,...
