Comment revenir à une version antérieure de Jellyfin en toute sécurité après une mise à jour incompatible
Traitez une restauration de Jellyfin comme une récupération, et non comme une simple rétrogradation d’image : arrêtez la version défaillante, préservez son état et utilisez une sauvegarde connue comme fiable ou une copie de données compatible.
Après le début des migrations par une version majeure, un ancien binaire peut ne pas comprendre la base de données modifiée. Sur un serveur domestique, conservez l’état défaillant pour le diagnostic, verrouillez l’image cible et les plugins, restaurez dans un chemin isolé et ne rétablissez l’accès des utilisateurs qu’après avoir vérifié la connexion, les bibliothèques et le chemin de lecture qui échouait initialement.
Figez la version défaillante avant une nouvelle migration
La nouvelle version échoue après le démarrage ou la migration. Commencez par la vérification la moins invasive : arrêtez le conteneur, notez le condensat exact de l’image et les journaux, puis copiez ou créez un instantané des données actuelles avant de démarrer une ancienne image.
L’observation utile est précise : la sauvegarde de l’état se termine, la base de données est déjà migrée, le stockage est plein ou en lecture seule. Notez le résultat avant de modifier une autre variable. restaurer au lieu de rétrograder
Interprétez le cas au lieu de deviner. Si l’état est lisible, préservez-le et poursuivez ; si la migration est incomplète, privilégiez une sauvegarde antérieure à la mise à niveau ; si le stockage est défaillant, réparez-le avant la restauration.
Sélectionnez une image et un artefact d’état compatibles
L’état et les artefacts défaillants sont préservés. Commencez par la vérification la moins invasive : choisissez la dernière étiquette ou le dernier condensat d’image connu comme fiable et associez-le à la sauvegarde créée avant la version incompatible.
L’observation utile est précise : une sauvegarde antérieure à la mise à niveau existe, seule une sauvegarde plus récente est disponible, ou le plugin ou l’architecture diffère. Notez le résultat avant de modifier une autre variable.
Interprétez le cas au lieu de deviner. Si une sauvegarde antérieure à la mise à niveau existe, utilisez-la ; sinon, ne pointez pas l’ancienne image vers la base de données migrée ; si l’architecture diffère, testez d’abord le chemin pris en charge de manière isolée.
Restaurez dans un chemin isolé avant de remplacer la production
Une image et une sauvegarde compatibles sont sélectionnées. Commencez par la vérification la moins invasive : créez un conteneur temporaire avec l’image verrouillée, les données restaurées, l’UID/GID correspondant et aucun conflit de port public. conteneur de récupération isolé
L’observation utile est précise : la connexion et les bibliothèques se chargent, un avertissement de migration apparaît, ou l’assistant de configuration s’affiche. Notez le résultat avant de modifier une autre variable.
Interprétez le cas au lieu de deviner. Si l’état se charge, poursuivez avec la validation de la charge de travail ; si un avertissement de migration apparaît, arrêtez-vous et revérifiez l’association des versions ; si l’assistant s’affiche, le montage est incorrect et la source reste intacte.
Reproduisez l’échec initial avant de rétablir l’accès des utilisateurs
L’ancienne version démarre de manière isolée. Commencez par la vérification la moins invasive : connectez-vous avec un utilisateur existant, inspectez les bibliothèques, lancez la lecture qui échouait initialement, redémarrez une fois, puis répétez.
L’observation utile est précise : le chemin initial fonctionne deux fois, un plugin échoue, ou l’échec persiste. Notez le résultat avant de modifier une autre variable. test de lecture initial
Interprétez le cas au lieu de deviner. Si le chemin initial fonctionne deux fois, rétablissez le trafic et conservez l’état défaillant ; si un plugin échoue, désactivez uniquement ce plugin ; si l’échec persiste, arrêtez la restauration et reconstruisez à partir d’un état propre et compatible.
Produits recommandés
Assistance et conseils
Plus à lire
Jellyfin peut-il partager en toute sécurité un GPU ou un accélérateur avec un autre conteneur ?
Le partage du GPU est conditionnel : vérifiez la visibilité du périphérique et la prise en charge des pilotes, puis exécutez les deux charges...
Comment déterminer si une erreur Jellyfin provient du client ou du serveur
Une erreur Jellyfin relève du client lorsqu’elle ne concerne qu’un seul appareil ; elle relève du serveur lorsque plusieurs clients échouent avec le même...
Comment configurer le cache et le stockage temporaire de Jellyfin
Séparez les données persistantes, le cache reconstructible et le stockage temporaire pour le transcodage, puis vérifiez la capacité et les autorisations avec un véritable...
