Devriez-vous conserver les métadonnées multimédias sur le SSD ou avec la bibliothèque ?
Conservez la base de données et le cache actif du serveur multimédia sur un SSD, tout en stockant les fichiers NFO portables et certaines illustrations avec la bibliothèque lorsque la migration est importante.
Les « métadonnées » regroupent plusieurs éléments différents : la base de données de l’application, l’état utilisateur, les index, les caches, les illustrations téléchargées, les images de chapitres, les aperçus trickplay, les fichiers NFO associés, ainsi que les images sélectionnées manuellement. Les placer tous au même endroit entraîne soit une latence inutile sur disque dur, soit une portabilité limitée. Un serveur multimédia domestique fonctionne généralement mieux avec une organisation séparée, dont les limites de sauvegarde et de récupération sont documentées.
Classez les métadonnées avant de choisir un disque
Répertoriez la base de données de l’application, la configuration, les comptes utilisateur, l’historique de visionnage, les index, les caches, les miniatures, les affiches, les arrière-plans, les fichiers NFO, les sous-titres et les données des extensions. Classez chaque élément comme faisant autorité, portable, reconstructible ou temporaire.
La base de données de l’application et l’état utilisateur sont généralement spécifiques au serveur et changent fréquemment. Les fichiers NFO et les illustrations stockés à côté des fichiers multimédias sont des accompagnateurs au niveau des fichiers, lisibles par une autre bibliothèque compatible, tandis que les caches et les miniatures générées peuvent être supprimés.
Ne choisissez pas un emplacement en vous basant uniquement sur le nom du dossier global. Un répertoire appelé « metadata » peut contenir à la fois des modifications manuelles irremplaçables et des caches d’images faciles à régénérer ; son contenu nécessite donc des règles de sauvegarde et d’emplacement différentes.
Placez les bases de données, les index et les caches actifs sur un SSD
Les requêtes de base de données, la navigation dans la bibliothèque, les recherches, les mises à jour de l’état utilisateur et la recherche de miniatures impliquent de nombreuses petites opérations de lecture et d’écriture. Un SSD réduit la latence de ces opérations et les éloigne de la charge de travail séquentielle des fichiers multimédias.
Un stockage rapide ne dispense pas d’utiliser un système de fichiers fiable ni un volume suffisamment dimensionné. Un problème Jellyfin fait état de blocages de la base de données et d’une interface ne répondant plus pendant une utilisation normale, ce qui montre que la base de données de l’application est une dépendance opérationnelle active, et non un simple cache jetable.
Placez l’intégralité de l’unité persistante de données de l’application sur un SSD disposant de suffisamment d’espace libre, de snapshots et de sauvegardes. Évitez de placer la base de données active sur un partage réseau, sauf si l’application prend explicitement en charge son comportement en matière de verrouillage et de latence.
Conservez les fichiers NFO portables et les illustrations sélectionnées avec les fichiers multimédias lorsque cela est utile
Les fichiers NFO associés, les affiches locales, les libellés d’édition et les illustrations sélectionnées manuellement peuvent faciliter la reconstruction d’une bibliothèque dans une autre instance. Ils restent visibles dans le dossier du film lorsque la base de données de l’application est perdue.
La portabilité n’est pas garantie entre toutes les versions et tous les analyseurs. Un rapport de migration Jellyfin décrit des fichiers NFO existants qui ont été ignorés et écrasés après un déplacement ; il est donc nécessaire d’effectuer un test d’importation avant de compter sur les fichiers associés comme seul moyen de récupération.
Ne stockez que les métadonnées que l’application peut lire de manière fiable et que vous souhaitez conserver. Gardez une sauvegarde des fichiers sélectionnés manuellement et empêchez les fournisseurs automatiques de les écraser sans effectuer un test contrôlé.
Respectez les limites liées aux bibliothèques en lecture seule et aux permissions
Un montage multimédia en lecture seule protège les fichiers sources contre les modifications accidentelles de l’application, mais il empêche également le serveur d’écrire des fichiers NFO, des illustrations, des collections et des aperçus locaux à côté de la bibliothèque.
Un problème Jellyfin a révélé que la création d’une collection échouait avec un système de fichiers multimédia en lecture seule, même si la configuration de l’application était accessible en écriture sur un SSD. Ce cas montre pourquoi l’emplacement d’écriture influence les fonctionnalités liées aux métadonnées.
Si l’immutabilité des sources est importante, gardez les fichiers multimédias en lecture seule et dirigez les métadonnées gérées par l’application vers son volume SSD. N’accordez un accès en écriture à la bibliothèque que lorsque les fichiers associés locaux font intentionnellement partie du plan de récupération, et limitez cet accès à l’identité du service.
Séparez les données d’aperçu reconstructibles de l’état critique
Les images trickplay, les miniatures de chapitres, les grilles d’aperçu extraites et les caches temporaires peuvent devenir beaucoup plus volumineux que la base de données principale. Ils ont également une valeur de sauvegarde différente, car ils peuvent souvent être régénérés.
Jellyfin propose des options permettant d’enregistrer les illustrations et les images trickplay à côté des fichiers multimédias, ce qui améliore la visibilité et la migration dans certaines configurations. Le code source de son interface décrit l’emplacement des illustrations locales et des éléments trickplay comme des choix distincts, plutôt que comme un emplacement universel unique pour les métadonnées.
Utilisez un cache dédié ou un sous-volume de métadonnées lorsque la croissance des aperçus devient importante. Sauvegardez la base de données et les métadonnées manuelles plus fréquemment que les miniatures reconstructibles, et documentez les dossiers pouvant être supprimés pendant la récupération.
Choisissez l’organisation selon vos besoins de récupération et de migration
Utilisez des métadonnées d’application stockées exclusivement sur SSD lorsqu’un seul serveur gère la bibliothèque, que le montage multimédia doit rester en lecture seule et que la rapidité de navigation importe davantage que la portabilité au niveau des fichiers. Utilisez des fichiers NFO et des illustrations locales lorsque les métadonnées sélectionnées doivent accompagner les fichiers ou que plusieurs outils compatibles partagent la bibliothèque.
Une organisation séparée offre généralement la meilleure séparation : base de données, utilisateurs, index et caches actifs sur SSD ; fichiers multimédias sources sur un stockage de capacité ; fichiers NFO sélectionnés et illustrations choisies à côté des fichiers multimédias ; aperçus volumineux et reconstructibles dans un cache dimensionné séparément ou à un emplacement local pris en charge.
| Type de données | Emplacement privilégié | Priorité de sauvegarde |
|---|---|---|
| Base de données de l’application, utilisateurs, état de visionnage | Volume SSD de l’application | Élevée |
| Index et cache actif | SSD ou cache dédié | Faible à moyenne |
| Fichiers NFO et illustrations sélectionnés | À côté des fichiers multimédias lorsque la portabilité est importante | Élevée s’ils ont été modifiés manuellement |
| Images trickplay et de chapitres | Cache dimensionné ou emplacement local pris en charge | Généralement reconstructibles |
| Films et séries sources | Stockage de capacité | Selon leur remplaçabilité |
Le guide ZimaSpace consacré au choix des disques NAS pour les charges de travail liées aux applications et aux métadonnées fournit le contexte de performances de stockage nécessaire à cette organisation séparée.
Vérifiez l’organisation avec des tests de sauvegarde et de restauration
Arrêtez le serveur multimédia et sauvegardez le volume SSD de l’application ainsi que toutes les métadonnées associées stockées avec la bibliothèque. Restaurez-les dans une instance isolée en utilisant les mêmes chemins de conteneur et les mêmes permissions.
Vérifiez que les utilisateurs, l’historique de visionnage, les collections, les correspondances manuelles, les illustrations et un élément avec trickplay sont restaurés comme prévu. Effectuez ensuite une seconde récupération en utilisant uniquement les fichiers multimédias et les fichiers associés afin de déterminer ce qui serait perdu sans la base de données de l’application.
L’organisation est correcte lorsque la navigation reste réactive, que la croissance du stockage de l’application est prévisible, que les fichiers multimédias peuvent rester en lecture seule comme prévu et que la sauvegarde documentée recrée chaque élément non reconstructible. Ne modifiez l’emplacement qu’après qu’un test de restauration a révélé un véritable problème de vitesse, de capacité ou de portabilité.
Produits recommandés
Assistance et conseils
Plus à lire
Plex peut-il partager un GPU avec un autre conteneur Docker ?
Plex et un autre conteneur peuvent souvent accéder au même GPU, mais vous devez tester la prise en charge des pilotes, le mappage des...
Comment déterminer si une erreur Plex vient du client ou du serveur
Reproduisez le même élément sur un autre client, comparez le chemin de session, puis recueillez les preuves côté serveur uniquement après que la portée...
Comment configurer le cache de Plex et le stockage temporaire du transcodage
Protégez l’état persistant de Plex en plaçant les fichiers temporaires de transcodage sur un stockage local adapté, puis vérifiez le nettoyage, l’espace libre et...
