Pouvez-vous conserver l’historique des contenus regardés lors de la migration d’un serveur multimédia ?
Oui, l’historique de visionnage peut être conservé lorsque la migration transfère la base de données des utilisateurs, l’identité des contenus multimédias et l’état compatible de l’application vers le nouveau serveur.
Copier uniquement les fichiers vidéo ne transfère pas les indicateurs de visionnage, les positions de reprise, les favoris, les comptes utilisateurs ni les choix par piste. Ces informations sont stockées dans la base de données persistante du serveur multimédia et associées aux identifiants des utilisateurs et des contenus. La méthode la plus sûre consiste à effectuer une migration complète d’une instance vers une autre sur la même plateforme, avec une sauvegarde cohérente réalisée serveur arrêté, des versions correspondantes, des chemins de conteneur stables et un test de restauration isolé avant que la destination ne devienne le serveur actif.
Déterminez si vous déplacez une instance ou changez de plateforme
Une migration de la même application d’un hôte vers un autre peut généralement préserver l’état complet du serveur. Un passage de Plex à Jellyfin, d’Emby à Jellyfin ou vers une autre plateforme nécessite un export, un service de synchronisation, un plug-in ou une traduction via API, car les bases de données utilisent des schémas et des identifiants différents.
Les utilisateurs de Jellyfin ont demandé un export plus simple des comptes, de l’historique de visionnage et des paramètres utilisateur précisément parce que les données utilisateur ne se résument pas à une simple copie de dossier multimédia.
Choisissez une méthode avant de commencer : une restauration complète de l’instance pour le même serveur multimédia, ou un transfert documenté de l’état de visionnage en cas de changement de plateforme. Ne combinez pas les deux en copiant partiellement une base de données dans une destination nouvellement analysée.
Sauvegardez l’intégralité de l’état persistant du serveur
Répertoriez la configuration, la base de données, les utilisateurs, les plug-ins, les métadonnées, les certificats, les paramètres des tâches planifiées et l’environnement du conteneur. Notez la version de l’application en cours d’exécution, le tag de l’image, l’emplacement de la base de données et tous les points de montage persistants.
L’état de visionnage peut inclure bien plus qu’une valeur booléenne. Une discussion Jellyfin identifie des champs tels que le statut de visionnage, le nombre de lectures, la position de lecture, la date de dernière lecture, les favoris et les pistes sélectionnées dans les enregistrements de données utilisateur.
Sauvegardez l’ensemble pris en charge des données persistantes au lieu d’exporter une seule table, sauf si aucune méthode de restauration complète n’existe. Une transplantation partielle de la base de données peut préserver un champ tout en endommageant les identifiants utilisateur, les références multimédias, les attentes du schéma ou l’historique des migrations plus récentes.
Arrêtez le serveur ou utilisez un instantané cohérent de la base de données
Empêchez la lecture, les analyses, l’actualisation des métadonnées et les modifications utilisateur pendant la création de la sauvegarde finale. Arrêtez le processus du serveur multimédia avant de copier les fichiers SQLite, sauf si le stockage et l’application prennent en charge une méthode de sauvegarde en ligne cohérente.
Une discussion sur les sauvegardes Jellyfin avertit que la copie de fichiers SQLite actifs peut capturer un état incohérent, car la base de données peut être utilisée pendant une sauvegarde ordinaire du système de fichiers.
Après l’arrêt du service, enregistrez les sommes de contrôle et les tailles des fichiers, puis laissez le serveur source inchangé jusqu’à ce que la destination ait passé les vérifications. Ne laissez pas les deux serveurs écrire dans la même base de données ou la même cible de synchronisation de l’état de visionnage pendant le basculement.
Maîtrisez les versions de l’application et le sens des mises à niveau
Restaurez d’abord, si possible, avec la même version de l’application. Vérifiez que les plug-ins, le schéma de la base de données et les chemins des conteneurs correspondent avant de mettre la destination à niveau.
Les migrations de bases de données peuvent être irréversibles, et une instance restaurée peut échouer lorsque l’état de migration enregistré ne correspond pas au schéma réel. Un problème actuel de Jellyfin documente un conflit d’état de migration après restauration.
Démarrez le serveur restauré sans accès public des clients, consultez son journal de migration et créez un nouvel instantané avant toute mise à niveau. Ne testez jamais une version plus récente avec l’unique copie de la base de données en espérant ensuite que l’ancienne version du serveur pourra la rouvrir.
Préservez des chemins multimédias et une identité des éléments stables
Conservez les mêmes chemins visibles dans le conteneur, même si les disques de l’hôte changent. Par exemple, remappez un nouveau pool de stockage vers les chemins existants /media/movies et /media/tv au lieu d’attribuer à la destination de nouvelles racines de bibliothèque.
La modification des chemins peut créer de nouveaux enregistrements multimédias ou laisser d’anciennes entrées à côté des éléments restaurés. Un problème Jellyfin associe la suppression de chemins de bibliothèque à des métadonnées obsolètes persistantes et à un comportement en double dans la section de reprise de lecture.
Vérifiez un film et un épisode par leur chemin de fichier et leur identité interne avant de lancer une analyse complète. Si la destination considère chaque fichier comme nouveau, arrêtez-vous et corrigez le mappage des chemins avant que les liens d’état de visionnage ne soient répartis entre des enregistrements en double.
Conservez la cohérence des utilisateurs et de leurs identifiants
Restaurez les utilisateurs avec la base de données au lieu de recréer manuellement des comptes portant les mêmes noms affichés. Un nom d’utilisateur visible ne prouve pas que l’utilisateur de destination possède le même identifiant interne.
La restauration manuelle de l’historique cible généralement la table des données utilisateur, mais ces enregistrements dépendent à la fois des références utilisateur et multimédias. Le déplacement des bibliothèques sans perte de métadonnées nécessite donc une gestion rigoureuse des chemins et de la base de données, plutôt que d’une nouvelle analyse aveugle des fichiers déplacés.
Après la restauration, connectez-vous avec chaque utilisateur représentatif et comparez les indicateurs de visionnage, les contenus en cours, les positions de reprise, les favoris, les choix audio et les choix de sous-titres. Ne jugez pas la réussite uniquement depuis le compte administrateur.
Utilisez une méthode de synchronisation ou d’export pour les changements de plateforme
Lorsque les applications source et destination sont différentes, exportez l’historique via un plug-in pris en charge, un outil API ou un service neutre de suivi du visionnage. Testez un petit échantillon avant de synchroniser l’intégralité de la bibliothèque.
Associez explicitement les utilisateurs et les titres, et considérez les épisodes, éditions, versions alternatives et fichiers renommés comme des conflits d’identité potentiels. Le seul titre d’un film est un critère trop faible lorsque plusieurs années ou versions portent le même nom.
Conservez un export de l’historique source même après la réussite de la première importation. Le transfert doit pouvoir être répété ou audité afin de corriger les utilisateurs manquants et les titres mal associés sans devoir recommencer la migration.
Effectuez une restauration isolée et ne basculez qu’après vérification
Démarrez la destination sur un port temporaire, avec les analyses planifiées, les webhooks et la synchronisation externe désactivés. Vérifiez les utilisateurs, le nombre d’éléments des bibliothèques, le total des contenus visionnés, les positions de reprise, les listes de lecture, les collections et plusieurs titres sélectionnés aléatoirement.
Le processus de migration des données NAS de ZimaSpace fournit la règle générale : conservez la source jusqu’à ce que l’état copié ait été vérifié depuis la destination.
La migration n’est terminée que lorsque l’instance restaurée redémarre correctement, que les chemins restent stables, que les utilisateurs représentatifs conservent leur historique et qu’une nouvelle lecture met correctement à jour la destination. Gardez la source hors ligne mais récupérable jusqu’à ce que le nouveau serveur ait fonctionné normalement pendant plusieurs jours et qu’une nouvelle sauvegarde ait été effectuée.
Produits recommandés
Assistance et conseils
Plus à lire
Pourquoi la restauration d’un volume Docker recrée-t-elle le contenu des fichiers, mais supprime-t-elle les attributs étendus ?
Un diagnostic de restauration de volume couvrant l’inventaire des xattr, les options de tar et de Rsync, les espaces de noms, la prise en...
Pourquoi un conteneur en cours d’exécution conserve-t-il son ancienne limite de mémoire après la modification du fichier Compose ?
Un diagnostic des limites mémoire couvrant les cgroups actifs, le redémarrage par rapport à la recréation, les champs Compose, les limites strictes et souples,...
Pourquoi le redémarrage d’un proxy inverse invalide-t-il toutes les sessions d’une application auto-hébergée ?
Un diagnostic de perte de session couvrant la portée des redémarrages, la propriété des cookies, la rotation des secrets, les sessions adossées au cache,...
