Comment migrer Jellyfin d’un ordinateur de bureau vers une plateforme multimédia open source
Migrez Jellyfin en attribuant des rôles distincts à l’état de l’application, aux médias, au cache, aux sauvegardes et à l’accès réseau avant de choisir les 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 si chaque chemin, UID/GID, dépendance de service et procédure de restauration est défini avant le démarrage du premier conteneur. Conservez l’ordinateur de bureau comme source de retour arrière jusqu’à ce qu’un redémarrage complet et un véritable test avec un client soient concluants.
Répartissez l’ordinateur de bureau en rôles de service
Inventoriez la configuration et la base de données de Jellyfin, les bibliothèques multimédias, les métadonnées et le cache d’images, les extensions, le cache de sous-titres, les utilisateurs, ainsi que toute dépendance au proxy inverse ou au DNS. Classez chaque élément comme état d’application persistant, média irremplaçable, cache régénérable, 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 multimédia en miroir comme une deuxième sauvegarde.
La frontière de migration est claire lorsque chaque rôle a un responsable, une destination, un chemin d’accès et une procédure de restauration. Si un rôle ne peut pas être restauré indépendamment, gardez-le sur l’ordinateur de bureau jusqu’à ce que la conception de la pile soit révisée.
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 surveillance 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 de dossiers (notes sur la migration de Jellyfin tenant compte des chemins).
Préservez les chemins et les permissions pendant le transfert
Arrêtez le service sur le poste de bureau, faites une copie de ses données persistantes et vérifiez-la avant toute transformation. Sur la cible, conservez autant que possible le chemin des médias dans le conteneur identique à celui enregistré dans la base de données. Définissez l’UID/GID du conteneur sur un principal pouvant lire les médias et écrire uniquement dans les répertoires requis par l’application. Testez une analyse de bibliothèque et une connexion utilisateur avant d’importer des plug-ins 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 permissions 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.
Valider la lecture, les utilisateurs et la récupération par étapes
Lancez la lecture directe en local, un transcodage représentatif, les sous-titres et un deuxième compte utilisateur. Arrêtez-vous ensuite et recréez la pile à partir de la définition Compose ou du déploiement, et non depuis un shell interactif. Restaurez la sauvegarde des données de l’application dans un emplacement de test propre et vérifiez que l’état de lecture, les utilisateurs et les chemins des bibliothèques sont préservés ou reconstruits volontairement.
Ce n’est qu’après ces vérifications que vous devriez ajouter l’accès à distance ou des services supplémentaires. Un hôte compact tel que ZimaCube 2 AI NAS 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éfinir les limites d’extension et d’arrêt
Ajoutez de la capacité en ajoutant un niveau de stockage, un nœud de calcul capable de transcoder ou un rôle réseau distinct ; ne répondez pas à chaque nouvelle charge de travail en agrandissant un volume partagé unique. Conservez la copie de retour arrière sur le poste de bureau tant qu’un plug-in, une conversion de chemins ou une migration d’utilisateur n’a pas été vérifié. La pile est prête lorsqu’une reconstruction documentée donne le même accès à la bibliothèque et le même résultat de lecture sans que le poste de bureau d’origine soit en marche.
Produits recommandés
Configuration de NAS et de serveur
À lire aussi
Un serveur de dortoir peut-il fonctionner assez silencieusement pour dormir, étudier et passer des appels vidéo ?
Oui, un serveur dans une chambre universitaire peut rester discret si le matériel consomme peu, si les vibrations des disques de stockage sont maîtrisées,...
Un homelab étudiant qui passe de la chambre universitaire au premier appartement
Gardez un homelab étudiant portable en séparant les services du réseau propre à chaque pièce, en réduisant le matériel au minimum, en sauvegardant son...
Comment partager un serveur domestique avec des colocataires sans partager de comptes ni de fichiers privés
Attribuez à chaque colocataire une identité nominative, un espace de stockage privé et uniquement les rôles partagés dont il a besoin ; séparez l’administration,...
