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 éléments du déploiement : l’état persistant de Jellyfin et la définition exacte du conteneur qui permet d’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 un mappage de périphérique oublié ne l’est pas.

Suivez la liste de contrôle dans l’ordre des dépendances. Vérifiez d’abord que vous pouvez récupérer les données, consignez ensuite l’image et les paramètres d’exécution actuels, puis consultez le parcours de mise à niveau et ne remplacez l’image qu’ensuite. 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 récupération.

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

Enregistrez la balise actuelle de l’image Jellyfin et, si possible, son condensat. Exportez ou copiez le fichier Compose ou la définition de l’application contenant les ports, les réseaux, les montages, les valeurs d’environnement, la politique de redémarrage, le mappage utilisateur, les groupes supplémentaires, les périphériques GPU et tout lien avec un proxy inverse.

La documentation officielle des conteneurs Jellyfin distingue les balises mobiles, comme latest, des balises explicites correspondant aux versions majeure, mineure et corrective. Fonctionnement des balises d’image Jellyfin Le retour à une version précédente est plus facile si vous connaissez exactement la version qui fonctionnait, au lieu de vous souvenir seulement que « latest fonctionnait hier ».

Ne supprimez pas l’ancienne image ni la définition enregistrée avant que la nouvelle version ait 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 offrent la méthode de récupération la moins intrusive.

Créer 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 changer l’image. La sauvegarde doit se trouver en dehors du chemin d’application actif et être lisible de manière indépendante ; une deuxième copie ou un instantané sur le même jeu de données n’est utile que si vous comprenez contre quel type de panne 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 une fois les migrations appliquées. Elle décrit également les sauvegardes intégrées et l’obligation d’arrêter proprement le serveur avant de copier manuellement les fichiers. Guide de sauvegarde et de restauration de Jellyfin

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

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

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

Le guide des conteneurs 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 sous un UID/GID spécifié. chemins persistants et mappage des utilisateurs Ces valeurs sont des dépendances, pas de la décoration : un conteneur recréé peut démarrer correctement tout en voyant un répertoire de configuration vide ou en perdant l’accès à un appareil.

Comparez la définition enregistrée au conteneur réellement en cours d’exécution, et pas seulement à 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 NAS, corrigez cet écart avant la mise à niveau afin de pouvoir reproduire le déploiement précédent.

Featured

NAS cloud personnel et domestique ZimaCube 2

ZimaCube2

$799.00 - $2,499.00

Buy Now

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

Lisez les notes de version pour chaque étape majeure entre la version actuelle et la version cible. Vérifiez la présence de versions intermédiaires obligatoires, de migrations de base de données, de changements de configuration, de problèmes de compatibilité des plug-ins, d’exigences liées à FFmpeg ou de longues opérations au démarrage.

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

Si un plugiciel est essentiel, vérifiez qu’une version compatible est disponible avant la mise à niveau du serveur. Si un plugiciel est facultatif et a déjà empêché le démarrage, notez sa version actuelle et soyez prêt à désactiver uniquement ce plugiciel si les journaux du nouveau serveur l’identifient comme la source du problème.

Effectuez la mise à niveau sans modifier la frontière de persistance

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

Surveillez le journal du premier démarrage. Une migration peut légitimement prendre du temps avec une grande bibliothèque, tandis qu’un message immédiat « permission denied », signalant une base de données vide, un chemin manquant ou un schéma incompatible, indique une autre cause. Ne redémarrez pas plusieurs fois une migration simplement parce que l’interface utilisateur n’est pas disponible immédiatement.

Si le conteneur démarre comme un nouveau serveur, 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 des montages ; la configuration d’une nouvelle instance vide peut créer des fichiers qui compliquent la récupération.

Validez la nouvelle version avant de supprimer les éléments nécessaires au retour arrière

Vérifiez l’identité d’origine du serveur, les utilisateurs, les bibliothèques, les métadonnées et les paramètres importants. Lancez la lecture d’un élément en lecture directe et d’un transcodage représentatif, puis exécutez ou observez une tâche planifiée importante pour votre configuration. Consultez les journaux pour repérer les erreurs récurrentes liées à la migration, à la base de données, aux permissions 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 accéder aux mêmes appareils après une recréation ou un redémarrage propre. Cela permet de détecter toute dépendance accidentelle à un montage temporaire ou à un état d’exécution.

Conservez la sauvegarde antérieure à 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 d’activité habituelle. Si un retour arrière est nécessaire après une migration de base de données, respectez la procédure de restauration documentée par Jellyfin au lieu de pointer une image plus ancienne vers un état déjà migré.