Les chemins de données de Jellyfin expliqués : ce qui doit être conservé et ce qui peut être recréé
Jellyfin est plus sûr à exploiter lorsque l’état de la base de données, la configuration, les métadonnées, le cache, les transcodages temporaires et les médias sont traités comme des rôles de données différents.
Tous les répertoires ne méritent pas le même niveau de stockage ni la même politique de sauvegarde : les comptes utilisateurs et l’état de visionnage doivent survivre au remplacement de l’environnement d’exécution, tandis que le cache et les fichiers temporaires de transcodage peuvent généralement être recréés, et que les médias restent stockés ailleurs comme source de référence. La séparation de ces rôles empêche qu’une mise à jour du conteneur ou un nettoyage du disque ne transforme accidentellement le serveur en une installation vierge. Définissez la persistance selon que les données doivent ou non survivre à une reconstruction propre de l’environnement d’exécution.
La base de données et la configuration définissent l’état du serveur
La base de données et la configuration contiennent les utilisateurs, les définitions des bibliothèques, les préférences, l’historique de visionnage et d’autres données liées à l’identité. Les perdre peut laisser les fichiers multimédias intacts, tout en faisant effectivement repartir le serveur de zéro.
L’état de configuration de Jellyfin comprend les comptes utilisateurs, les paramètres des bibliothèques, l’historique de visionnage et les métadonnées, qui doivent être protégés séparément des fichiers multimédias volumineux.
Conservez cet état sur un chemin persistant, en dehors de l’image ou du paquet remplaçable. Une organisation persistante des données d’application fournit à l’environnement d’exécution un emplacement stable auquel se reconnecter après une recréation.
Les métadonnées sont précieuses, mais ne se confondent pas avec la base de données
Les illustrations et les métadonnées générées peuvent être coûteuses à recréer à grande échelle, même si certaines informations sources restent récupérables. Leur priorité de restauration dépend de la quantité de curation manuelle et de traitement qu’elles contiennent.
Conserver les données du conteneur sur un SSD tandis que les médias volumineux restent sur un HDD crée une nette séparation entre les données d’application sur SSD et les médias sur HDD, ce qui distingue la latence de navigation du stockage haute capacité des médias.
Mesurez la taille des métadonnées et le coût de leur reconstruction avant de décider si elles doivent figurer dans chaque niveau de sauvegarde. Traitez différemment les ressources modifiées manuellement ou difficiles à régénérer et le cache jetable.
Le cache et les fichiers temporaires de transcodage doivent suivre un modèle d’expiration
Le cache et les sorties de transcodage actif servent à accélérer ou à prendre en charge le travail en cours, et non à définir l’identité à long terme du serveur. Les préserver systématiquement augmente la taille des sauvegardes et peut restaurer un état temporaire obsolète.
Une architecture de stockage pour serveur multimédia sépare le cache local des médias durables, car les tâches temporaires à forte activité ont des besoins différents en matière de latence et de durabilité.
Placez les fichiers temporaires sur un chemin rapide et surveillez explicitement l’espace libre. Vérifiez que le service peut les recréer après leur suppression avant de les exclure des sauvegardes.
Les médias doivent rester un niveau de données de référence distinct
Les fichiers de la bibliothèque peuvent se trouver sur des disques locaux ou un NAS et dépasser de plusieurs ordres de grandeur le volume de l’état de l’application. Ils nécessitent leur propre décision en matière de redondance et de sauvegarde, plutôt que d’hériter de la politique appliquée à la base de données.
La capacité et l’activité varient selon les jeux de données ; un seul modèle de rétention convient donc rarement à la fois à l’état de l’application et aux médias volumineux.
Documentez le chemin faisant autorité pour chaque rôle et testez une restauration au cours de laquelle l’état de Jellyfin se reconnecte à une bibliothèque multimédia inchangée. Une cartographie claire des rôles rend les futures migrations de stockage beaucoup moins ambiguës.
Produits recommandés
Centre Tech & IA
Plus à lire
Pourquoi l’architecture d’un serveur personnel Jellyfin évolue à mesure que vous ajoutez des services
Un boîtier Jellyfin devient une pile de services à mesure que l’on ajoute des applications : la gestion du processeur, du stockage, du réseau,...
Comment mesurer les performances de Jellyfin sans confondre cache et capacité
Un benchmark Jellyfin fiable distingue les états à froid et à chaud afin que les métadonnées mises en cache ou les pages du système...
De quelle marge de manœuvre l’iGPU de Jellyfin multi-utilisateur a-t-il besoin ?
La marge disponible de l’iGPU pour Jellyfin dépend de la charge de travail : prévoyez une marge au-delà du scénario de transcodage simultané reproductible...
