Comment migrer Jellyfin d’un ordinateur de bureau vers une pile multimédia open source

Migrez Jellyfin en attribuant des rôles explicites à l’état de l’application, aux médias, au cache, aux sauvegardes et à l’accès réseau avant de choisir des conteneurs ou un NAS.

Un ordinateur de bureau regroupe généralement tous les rôles dans un seul système de fichiers et sur une seule alimentation. Une pile multimédia open source sépare ces rôles : la migration ne réussit donc que lorsque chaque chemin, UID/GID, dépendance de service et action de restauration sont définis avant le démarrage du premier conteneur. Conservez l’ordinateur de bureau comme source de retour arrière jusqu’à la réussite d’un redémarrage propre et d’un véritable test client.

Transformez l’ordinateur de bureau en rôles de service

Inventoriez la configuration et la base de données Jellyfin, les bibliothèques multimédias, le cache des métadonnées et des images, les plugins, le cache des sous-titres, les utilisateurs, ainsi que toute dépendance à un proxy inverse ou au DNS. Classez chaque élément comme état applicatif persistant, média irremplaçable, cache reconstructible, copie de sauvegarde ou média de récupération. Ne copiez pas un cache comme s’il s’agissait d’une base de données et ne considérez pas un volume de médias en miroir comme une seconde sauvegarde.

La limite de migration est clairement définie lorsque chaque rôle possède un responsable, une destination, un chemin d’accès et une action de restauration. Si un rôle ne peut pas être restauré indépendamment, conservez-le sur l’ordinateur de bureau jusqu’à la révision de l’architecture de la pile.

Choisissez la topologie cible avant de sélectionner les images

Utilisez un rôle de service pour Jellyfin, un volume de données persistant pour sa configuration et sa base de données, un volume multimédia avec des chemins stables et une destination de sauvegarde distincte. Placez le proxy inverse, la supervision et les services expérimentaux sur leurs propres chemins ou réseaux lorsque le couplage des défaillances est important. Un outil de migration tiers montre pourquoi la traduction des chemins et la gestion de la base de données nécessitent un plan explicite plutôt qu’une simple copie aveugle de dossier (notes sur la migration Jellyfin tenant compte des chemins).

Préservez les chemins et les autorisations pendant le transfert

Arrêtez le service de l’ordinateur de bureau, faites une copie de ses données persistantes et vérifiez cette copie avant de la transformer. Sur la cible, conservez autant que possible le chemin des médias à l’intérieur du conteneur identique à celui enregistré dans la base de données. Définissez l’UID/GID du conteneur sur un principal capable de lire les médias et d’écrire uniquement dans les répertoires applicatifs nécessaires. Testez l’analyse d’une bibliothèque et la connexion d’un utilisateur avant d’importer des plugins ou d’ajouter des automatisations.

La décision est PASS lorsque Jellyfin peut lire toutes les bibliothèques prévues, écrire dans sa base de données et redémarrer sans modifier la correspondance des chemins. Si les autorisations exigent un accès en écriture étendu à l’arborescence des médias, séparez les rôles des données et de l’application avant de poursuivre.

-15% OFF

ZimaBoard 2 - Mini serveur domestique pour votre grande idée

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Validez la lecture, les utilisateurs et la récupération par étapes

Exécutez une lecture directe locale, un transcodage représentatif, un test des sous-titres et un test avec un deuxième compte utilisateur. Arrêtez ensuite la pile et recréez-la à partir de la définition Compose ou du déploiement, et non depuis un shell interactif. Restaurez la sauvegarde des données applicatives dans un emplacement de test propre et vérifiez que l’historique de visionnage, les utilisateurs et les chemins des bibliothèques sont préservés ou reconstruits intentionnellement.

Ce n’est qu’après ces vérifications que vous devrez ajouter l’accès distant ou des services supplémentaires. Un hôte compact tel que ZimaCube 2 NAS IA peut être envisagé lorsque les exigences neutres — stockage persistant, marge de capacité pour les conteneurs et chemin de sauvegarde distinct — correspondent déjà à la pile.

Définissez les limites d’extension et d’arrêt

Étendez la pile en ajoutant un niveau de stockage, un nœud de calcul capable de transcoder ou un rôle réseau distinct ; ne cherchez pas à résoudre chaque nouvelle charge de travail en agrandissant un seul volume partagé. Conservez la copie de retour arrière de l’ordinateur de bureau lorsqu’un plugin, une conversion de chemin ou une migration d’utilisateurs n’a pas été vérifié. La pile est prête lorsqu’une reconstruction documentée produit le même accès aux bibliothèques et le même résultat de lecture sans que l’ordinateur de bureau d’origine soit en fonctionnement.