Comment déplacer les données de Jellyfin sans perdre les utilisateurs, l’historique ni les paramètres
Pour déplacer Jellyfin sans perdre les utilisateurs ni l’historique, arrêtez la source avant de copier ses données persistantes et conservez l’instance d’origine intacte jusqu’à ce que la nouvelle ait passé la vérification.
Une migration de serveur domestique peut échouer même si tous les fichiers multimédias sont présents, car l’état de Jellyfin se trouve dans les chemins de données, de configuration, de métadonnées et de base de données. Répertoriez ces montages, copiez-les une fois les écritures suspendues, recréez les mêmes chemins et propriétaires, puis testez la connexion, l’historique, l’accès aux bibliothèques et la lecture avant de retirer la source.
Geler la source et répertorier les chemins persistants
L’instance source sert encore les utilisateurs. Commencez par la vérification la moins invasive : notez les chemins de données/configuration/cache de Jellyfin, les montages du conteneur, l’UID/GID, la version et les emplacements des fichiers multimédias ; arrêtez le conteneur avant de copier l’état.
L’observation utile est précise : tous les chemins d’état sont montés, le chemin de la base de données est masqué dans un volume, seuls les fichiers multimédias sont mappés. Notez le résultat avant de modifier une autre variable. sauvegarde avant migration
Interprétez la situation au lieu de deviner. Si tous les chemins persistants sont connus, continuez ; si un chemin est masqué, résolvez-le d’abord ; si seuls les fichiers multimédias sont mappés, créez une sauvegarde de l’état avant de copier.
Copier les données, la configuration et la base de données en conservant les propriétaires
La source est arrêtée et les chemins sont répertoriés. Commencez par la vérification la moins invasive : copiez d’abord les répertoires d’état, comparez le nombre et la taille des fichiers, puis appliquez l’UID/GID de destination et confirmez que Jellyfin peut lire et écrire dans sa base de données.
L’observation utile est précise : la base de données s’ouvre correctement, une erreur d’accès refusé apparaît, les chemins existent mais les bibliothèques sont vides. Notez le résultat avant de modifier une autre variable. chemin de la base de données locale
Interprétez la situation au lieu de deviner. Si la base de données s’ouvre et que les chemins correspondent, continuez ; si les autorisations échouent, corrigez les propriétaires sans supprimer de fichiers ; si les bibliothèques sont vides, réparez les chemins de montage avant de relancer l’analyse.
Recréer l’environnement d’exécution avant de tester le résultat
Les données persistantes sont copiées et les propriétaires sont corrigés. Commencez par la vérification la moins invasive : recréez le conteneur avec les montages de destination, notez la version de l’image et ouvrez le tableau de bord d’administration avant de modifier les bibliothèques ou les utilisateurs.
L’observation utile est précise : les utilisateurs et les bibliothèques apparaissent, une migration au démarrage s’exécute, l’assistant de configuration initiale apparaît. Notez le résultat avant de modifier une autre variable.
Interprétez la situation au lieu de deviner. Si l’état apparaît, ne relancez pas encore l’analyse ; si une migration s’exécute, laissez-la se terminer et conservez la source ; si l’assistant de configuration apparaît, arrêtez-vous, car le montage des données est incorrect.
Vérifier les utilisateurs, l’historique, les bibliothèques et la lecture avant le nettoyage
La nouvelle instance démarre avec l’état copié. Commencez par la vérification la moins invasive : connectez-vous avec un utilisateur existant, vérifiez l’historique de visionnage et les autorisations des bibliothèques, lisez un contenu en lecture directe et un autre nécessitant un transcodage, puis redémarrez une fois et répétez les tests.
L’observation utile est précise : l’état et la lecture fonctionnent, une bibliothèque est vide, des utilisateurs ou l’historique sont manquants. Notez le résultat avant de modifier une autre variable. procédure de vérification de la migration
Interprétez la situation au lieu de deviner. Si toutes les vérifications réussissent deux fois, conservez une sauvegarde finale et retirez la source ultérieurement ; si une vérification de l’état échoue, redirigez les clients vers la source ; si la lecture échoue, réparez le chemin ou l’accélérateur avant le nettoyage.
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...
