Jellyfin peut-il fonctionner sur ARM et x86 avec les mêmes données ?
Généralement oui, mais considérez le passage d’ARM à x86 comme une migration contrôlée de serveur plutôt que comme la preuve que chaque composant de Jellyfin est indépendant de l’architecture. Pour les versions actuelles de Jellyfin, la cible ARM concernée est ARM64 ; une destination x86 doit également être une plateforme 64 bits prise en charge. Conservez la source intacte jusqu’à ce que la destination ait réussi les vérifications de redémarrage et de lecture.
La limite importante est opérationnelle : arrêtez la source avant de copier les données persistantes et ne laissez jamais deux instances Jellyfin sur des hôtes différents écrire dans le même répertoire de données actif. Jellyfin ne documente pas la migration d’ARM64 vers x86-64 comme une procédure spéciale sans risque ; conservez donc une copie de restauration et reconstruisez séparément les éléments spécifiques à la plateforme, tels que les paquets FFmpeg, les mappages des périphériques d’accélération matérielle, les dépendances natives des extensions, les autorisations et les chemins d’accès de l’hôte.
Vérifiez que l’architecture de destination est réellement prise en charge
Commencez par confirmer que la destination est une plateforme Jellyfin 64 bits actuellement prise en charge. Ne partez pas du principe qu’une ancienne carte ARM, qu’un système d’exploitation 32 bits ou qu’une ancienne machine x86 convient simplement parce que Linux démarre encore dessus.
Jellyfin 10.11 a officiellement supprimé la prise en charge d’ARM32, notamment de armhf, et exige désormais un système d’exploitation ARM64 sur les plateformes ARM. Si la source utilise encore une ancienne version ARM 32 bits, prévoyez d’abord une destination 64 bits prise en charge au lieu de considérer l’ancien environnement comme une cible de migration actuelle.
Sur x86, utilisez un hôte x86-64 pris en charge qui répond aux exigences de la version de Jellyfin que vous prévoyez d’exécuter. Si la destination dépend d’un paquet non officiel, d’un système d’exploitation non pris en charge ou d’un processeur obsolète, corrigez ce problème de plateforme avant de déplacer les données persistantes.
Considérez l’état enregistré comme portable, mais le déploiement comme spécifique à la plateforme
Un déploiement Jellyfin standard conserve l’état persistant du serveur dans sa base de données, avec les fichiers de configuration et de métadonnées. Pour les installations utilisant SQLite, le format de la base de données sur disque est conçu pour être portable entre les architectures de processeur ; la famille de processeurs n’est donc pas, à elle seule, une raison de convertir la base de données avant la migration.
SQLite décrit son format de fichier comme un format de base de données multiplateforme, notamment portable entre les systèmes 32 bits et 64 bits et malgré les différences d’endianness. Cela concerne la portabilité du format de base de données, mais ne garantit pas que chaque extension Jellyfin, exécutable externe, pilote ou chemin propre au déploiement fonctionnera sans modification.
Gardez cette distinction à l’esprit : les enregistrements stockés et portables ne constituent qu’une seule couche. La compatibilité des versions de Jellyfin, la couverture complète des données et de la configuration, la cohérence des chemins multimédias, les dépendances des extensions, les autorisations et l’accès aux périphériques matériels déterminent également si la destination se comportera comme la source.
Arrêtez Jellyfin avant de déplacer l’état actif
Pour une migration d’architecture contrôlée, arrêtez le processus Jellyfin de la source avant de créer la copie de migration. Cela empêche une base de données active ou un état d’écriture anticipée de changer pendant la copie des fichiers et vous fournit un point de restauration cohérent.
Copiez l’ensemble des données et de la configuration plutôt que de sélectionner uniquement jellyfin.db. Une copie partielle peut conserver les utilisateurs tout en supprimant la configuration, les extensions, les métadonnées ou d’autres éléments attendus par la destination.
Le même modèle de protection que celui utilisé dans un plan de sauvegarde à plusieurs copies s’applique ici : conservez la source intacte jusqu’à ce que la destination ait réussi une véritable restauration et une validation de lecture.
Reconstruisez les éléments spécifiques à l’architecture sur le nouvel hôte
Installez le paquet Jellyfin natif de la destination ou utilisez l’image de conteneur multi-architecture appropriée. Recréez les mappages des périphériques GPU, les autorisations de groupe, les paquets FFmpeg et les chemins propres à l’hôte au lieu de copier les binaires de l’ancienne architecture.
Examinez les extensions après le premier démarrage. Les extensions qui dépendent de bibliothèques natives, de binaires inclus ou d’exécutables externes peuvent nécessiter une version correspondant à la nouvelle architecture. Désactivez une extension douteuse pendant la première validation si elle empêche le démarrage, puis réactivez-la uniquement après avoir confirmé sa compatibilité.
Si les chemins multimédias diffèrent entre les hôtes, conservez autant que possible les mêmes chemins grâce aux points de montage. Sinon, prévoyez une migration de chemins prise en charge au lieu de modifier manuellement les enregistrements internes de la base de données Jellyfin.
Validez la migration avant de réutiliser la source
Démarrez uniquement l’instance de destination et confirmez les utilisateurs, les bibliothèques, l’état de visionnage, les illustrations, les tâches planifiées, ainsi qu’une lecture directe et une transcodification requise. Consultez les journaux pour repérer les bibliothèques natives manquantes, les échecs d’autorisation ou les chemins faisant encore référence à l’ancien hôte.
Redémarrez deux fois la destination et répétez un test de lecture afin de vérifier que la réussite est persistante et non due à un démarrage ponctuel. Si la destination échoue, arrêtez-la et restaurez la copie de migration ou revenez à la source restée intacte, au lieu de laisser les deux instances écrire dans le même état.
La migration est terminée uniquement lorsque le nouvel hôte résiste à un redémarrage et à une utilisation domestique normale. Si vous souhaitez conserver l’ancienne machine disponible, attribuez-lui une copie restaurée distincte ou laissez-la éteinte ; n’utilisez pas un même répertoire de données Jellyfin actif comme stockage partagé entre des serveurs ARM et x86.
Produits recommandés
Assistance et conseils
Plus à lire
Jellyfin doit-il utiliser un compte partagé unique ou des comptes distincts pour chaque membre du foyer ?
Choisissez les comptes familiaux Jellyfin selon les limites d’identité, d’accès, de contrôle parental et de récupération dont vous avez besoin.
Pourquoi l’utilisation de la mémoire de Jellyfin reste-t-elle élevée une fois la tâche terminée ?
Distinguez la croissance du processus Jellyfin du cache Linux, et n’intervenez que lorsque la mémoire continue d’augmenter ou crée une réelle pression.
Signes indiquant qu’une configuration de stockage Jellyfin devient un risque pour la récupération des données
Auditez les rôles de stockage de Jellyfin, séparez l’état actif des sauvegardes et des données reconstructibles, puis validez la disposition par une restauration.
