Liste de vérification avant la mise à niveau des conteneurs Jellyfin et de leurs dépendances

Avant de mettre à niveau un conteneur Jellyfin, préservez les deux volets du déploiement : l’état persistant de Jellyfin et la définition exacte du conteneur qui sait comment y accéder. Il est facile de télécharger une nouvelle image ; récupérer une base de données migrée, un montage modifié ou une association d’appareil oubliée ne l’est pas.

Suivez la checklist dans l’ordre des dépendances. Vérifiez d’abord que vous pouvez restaurer les données, consignez ensuite l’image actuelle et les paramètres d’exécution, consultez alors le chemin de mise à niveau, puis remplacez seulement l’image. Après cela, testez les mêmes bibliothèques, utilisateurs, modes de lecture, tâches planifiées et comportements au redémarrage avant de supprimer la copie de restauration.

Consignez la dernière image fonctionnelle et la définition du conteneur

Enregistrez le tag de l’image Jellyfin actuelle et, lorsque c’est possible, son condensat. Exportez ou copiez le fichier Compose ou la définition de l’application contenant les ports, réseaux, montages, valeurs d’environnement, politique de redémarrage, mappage utilisateur, groupes supplémentaires, appareils GPU et éventuelle relation avec un proxy inverse.

La documentation officielle du conteneur Jellyfin distingue les tags mobiles tels que latest des tags explicites de version majeure, mineure et corrective. Comportement des tags d’image Jellyfin Une restauration est plus simple lorsque vous connaissez la version exacte qui fonctionnait, plutôt que de vous souvenir seulement que « latest fonctionnait hier ».

Ne supprimez pas l’ancienne image et n’effacez pas la définition enregistrée tant que la nouvelle version n’a pas passé toute la période de validation. Si la mise à niveau échoue avant de toucher aux données persistantes, l’image et la définition conservées vous offrent le chemin de récupération le moins invasif.

Créez une sauvegarde récupérable de l’état de Jellyfin

Protégez les répertoires de données et de configuration de Jellyfin avant de modifier l’image. La sauvegarde doit se trouver en dehors du chemin d’application actif et être lisible indépendamment ; une seconde copie ou un instantané sur le même jeu de données n’est utile que si vous comprenez contre quelle défaillance il vous protège.

La documentation de sauvegarde de Jellyfin avertit que les mises à niveau peuvent nécessiter une restauration des données, car il n’existe pas de mécanisme général de rétrogradation après l’application des migrations. Elle documente également les sauvegardes intégrées et l’exigence d’un arrêt propre pour les copies manuelles de fichiers. Conseils de Jellyfin sur la sauvegarde et la restauration

Dans un flux de travail avec conteneur, le même principe est couvert par le flux de travail de ZimaSpace pour créer un point de restauration avant la mise à jour. Arrêtez-vous ici si vous ne pouvez pas identifier les chemins persistants ou vérifier le contenu de la sauvegarde.

Capturez les montages, l’UID/GID et les dépendances matérielles

Répertoriez chaque montage lié et chaque volume nommé, en précisant s’il est en lecture seule ou accessible en écriture. Notez l’UID/GID d’exécution, les appartenances aux groupes et le propriétaire des répertoires de données appartenant à Jellyfin. Capturez également les mappages du GPU ou des appareils de rendu si l’accélération matérielle est activée.

Le guide du conteneur Jellyfin montre que les médias, la configuration et le cache sont montés séparément et que le conteneur peut s’exécuter avec un UID/GID spécifié. Chemins persistants et mappage utilisateur Ces valeurs sont des dépendances, pas des détails secondaires : un conteneur recréé peut démarrer correctement tout en voyant un répertoire de configuration vide ou en perdant l’autorisation d’accéder à un appareil.

Comparez la définition enregistrée avec le conteneur en cours d’exécution, et pas seulement avec un modèle que vous pensez à jour. Si l’environnement d’exécution comporte des modifications manuelles absentes de Compose ou de la définition de l’application du NAS, corrigez cette divergence avant la mise à niveau afin de pouvoir reproduire l’ancien déploiement.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Vérifiez le chemin de mise à niveau pris en charge et les risques liés aux extensions

Lisez les notes de version pour chaque changement de version majeure entre la version actuelle et la version cible. Recherchez les versions intermédiaires obligatoires, les migrations de base de données, les modifications de configuration, la compatibilité des extensions, les exigences de FFmpeg et les opérations de démarrage susceptibles de durer longtemps.

La documentation de mise à niveau de Jellyfin insiste à plusieurs reprises sur les sauvegardes et explique pourquoi les modifications de schéma peuvent rendre une simple rétrogradation impossible. Limites des mises à niveau et rétrogradations Les notes de version majeures peuvent ajouter des prérequis propres à une version ; ne déduisez donc pas qu’un saut est sûr simplement parce que l’image du conteneur existe.

Si une extension est essentielle, confirmez qu’une version compatible est disponible avant de mettre le serveur à niveau. Si une extension est facultative et a déjà empêché le démarrage, notez sa version actuelle et soyez prêt à désactiver uniquement cette extension si les journaux du nouveau serveur l’identifient comme source de l’échec.

Effectuez la mise à niveau sans modifier la limite d’état

Arrêtez proprement Jellyfin, téléchargez l’image prévue et recréez uniquement le service Jellyfin avec les mêmes chemins persistants et dépendances d’exécution vérifiés. Ne combinez pas la mise à niveau avec une migration du stockage, une refonte de l’UID/GID, une réécriture du proxy inverse et une reconfiguration du GPU, sauf si ces changements constituent réellement l’objectif de la maintenance.

Surveillez le premier journal de démarrage. Une migration peut légitimement prendre du temps avec une bibliothèque volumineuse, tandis qu’un message immédiat indiquant « permission denied », une base de données vide, un chemin manquant ou un schéma incompatible signale une autre branche de diagnostic. Ne redémarrez pas la migration à répétition simplement parce que l’interface n’est pas disponible immédiatement.

Si le conteneur s’ouvre comme un serveur vierge, arrêtez-le avant de le configurer. Ce symptôme signifie généralement que le nouveau service pointe vers le mauvais état persistant. Corrigez d’abord le mappage du montage ; configurer une nouvelle instance vide peut créer de nouveaux fichiers qui compliqueront la récupération.

Validez la nouvelle version avant de supprimer les éléments de restauration

Vérifiez l’identité du serveur d’origine, les utilisateurs, les bibliothèques, les métadonnées et les paramètres importants. Lancez un élément en lecture directe et un transcodage représentatif, puis exécutez ou observez une tâche planifiée importante pour votre configuration. Vérifiez dans les journaux la présence d’erreurs récurrentes liées aux migrations, à la base de données, aux autorisations et à FFmpeg.

Redémarrez le conteneur une fois après la première session réussie. La nouvelle version n’est pas entièrement validée tant qu’elle ne peut pas rouvrir les mêmes données et appareils après une recréation ou un redémarrage propre. Cela permet de détecter une dépendance accidentelle à un montage temporaire ou à un état d’exécution.

Conservez la sauvegarde précédant la mise à niveau, la référence de l’image précédente et la définition enregistrée jusqu’à ce que le serveur ait passé sa période de charge habituelle. Si une restauration est nécessaire après une migration de base de données, suivez la limite de restauration documentée par Jellyfin au lieu de pointer une ancienne image vers un état déjà migré.