Comment éviter la perte de configuration d’Immich lors des mises à niveau

Évitez toute perte de configuration d’Immich pendant les mises à niveau en traitant le fichier Compose, les valeurs d’environnement, la base de données, la bibliothèque de téléversements et les définitions de montage des bibliothèques externes comme des ressources persistantes distinctes qui doivent être sauvegardées et restaurées ensemble.

Un conteneur est remplaçable ; la configuration qui l’entoure ne l’est pas. Une mise à niveau peut donner l’impression d’effacer Immich lorsqu’un montage lié relatif est résolu depuis un autre répertoire de projet, lorsqu’une modification de l’environnement n’atteint jamais le conteneur recréé ou lorsque la nouvelle pile démarre avec une base de données vide. Inventoriez d’abord le déploiement actif, conservez des copies versionnées hors de l’hôte et vérifiez une recréation contrôlée avant le basculement en production.

Capturez le déploiement actif avant chaque mise à niveau

Exportez la configuration Compose effective en masquant les secrets, notez les versions ou condensats des images et copiez les fichiers Compose et d’environnement dans un stockage versionné. Inspectez les montages des conteneurs en cours d’exécution au lieu de supposer que le fichier ouvert dans votre éditeur a lancé les conteneurs actuels. La condition de réussite est que chaque chemin d’exécution corresponde à un emplacement hôte connu.

Notez les chemins des bibliothèques externes, les paramètres du proxy inverse, l’URL du machine learning, les valeurs de connexion à la base de données, l’identité de l’utilisateur et du groupe, les noms des réseaux et les périphériques d’accélération matérielle. Tout élément manquant ici deviendra plus tard une différence inexpliquée après la mise à niveau.

Les questions récurrentes de la communauté montrent que les opérateurs perdent souvent de vue la génération Compose ou la structure d’environnement applicables. La leçon utile d’une discussion sur la configuration d’une mise à niveau est de préserver la définition fonctionnelle actuelle avant de la traduire.

Sauvegardez séparément la base de données, les médias et les fichiers de déploiement

Effectuez une sauvegarde native de la base de données ainsi qu’une sauvegarde du système de fichiers ou un instantané de la bibliothèque de téléversements et du répertoire de déploiement. Notez les heures de début et de fin, la taille des archives et leurs sommes de contrôle. Une sauvegarde qui ne contient que le fichier YAML Compose peut reconstruire les conteneurs, mais ne peut pas restaurer les comptes, les métadonnées, les albums ou les enregistrements des ressources.

Utilisez une sauvegarde après arrêt pour bénéficier de la limite de cohérence la plus simple, ou coordonnez un vidage de la base de données en fonctionnement et un instantané du stockage afin de documenter leur relation. Répertoriez les bibliothèques externes même si Immich ne possède pas leurs fichiers d’origine, car les chemins et les règles d’accès influencent toujours le service restauré.

Une procédure de mise à niveau majeure maintenue par la communauté insiste sur la préservation de la base de données, des médias, de Compose et des entrées d’environnement. Considérez sa séquence comme un retour d’expérience d’opérateur et vérifiez chaque étape par rapport à la version que vous déployez réellement.

Préparez la mise à niveau avec des versions épinglées

Lisez les notes de version de chaque version intermédiaire ignorée et mettez à jour délibérément la définition de déploiement enregistrée. Épinglez la version cible, téléchargez-la sans supprimer les anciennes images et validez la configuration Compose rendue. Les variables inconnues, les montages vides ou les versions de services mélangées font échouer la validation de préparation.

Si la capacité le permet, restaurez la sauvegarde dans une pile de test isolée utilisant des ports différents et aucun accès en écriture à la production. Démarrez-la avec la version cible et inspectez les migrations, les utilisateurs, les chemins de stockage et les tâches en arrière-plan. Le simple démarrage réussi du conteneur ne prouve pas que la bibliothèque d’origine est connectée.

Le guide ZimaSpace associé consacré à un NAS auto-hébergé sécurisé aide à placer les fichiers de déploiement et les sauvegardes en dehors de la frontière unique de l’hôte et des identifiants qu’une mise à niveau peut perturber.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Vérifiez la persistance de la configuration après recréation

Avant le basculement, recréez les conteneurs de test à partir des fichiers enregistrés au lieu de simplement les redémarrer sur place. Vérifiez les utilisateurs, les paramètres du serveur, les modèles de stockage, les bibliothèques, les tâches, l’accès au proxy et les valeurs d’environnement effectives. La condition de réussite est que la configuration survive au remplacement, car elle réside dans des composants persistants documentés.

Après le basculement en production, téléversez une ressource de test, lancez une recherche, ouvrez un original et créez une nouvelle sauvegarde de la base de données. Redémarrez la pile et l’hôte, puis répétez ces vérifications. Conservez l’ancienne version, la sauvegarde et la définition de déploiement jusqu’à ce que la charge de travail normale reste stable pendant la période d’observation.

Si la mise à niveau a déjà démarré avec une configuration vide, arrêtez-la avant que l’ajout d’utilisateurs ou de nouveaux téléversements ne crée un état contradictoire. Reconnectez uniquement un chemin persistant vérifié ou restaurez dans une cible propre. Effectuez un retour arrière si des utilisateurs ou des ressources attendus sont absents ; transmettez une configuration Compose effective, des montages, des versions et des horodatages de sauvegarde assainis si l’identité reste ambiguë.