Quand Jellyfin doit-il utiliser une base de données ou un hôte de stockage distinct ?
Dans la plupart des foyers équipés de Jellyfin, séparez d’abord l’hôte de stockage des médias plutôt que celui de la base de données : conservez l’état de production de l’application sur un SSD local à faible latence et ne séparez les médias volumineux que si la capacité, la restauration ou l’emplacement l’exige.
Cette décision porte sur les rôles des données plutôt que sur le nombre de machines. Jellyfin comporte un état de configuration et de base de données sensible à la latence, des caches régénérables, des données temporaires de transcodage et de volumineux fichiers multimédias principalement séquentiels. Ces catégories tirent parti de différents types de stockage, de sauvegarde et de limites de panne. Un deuxième hôte n’est utile que s’il offre à un rôle un avantage plus net en matière de capacité ou de restauration, sans transformer une dépendance auparavant locale en un lien réseau fragile.
Séparez les rôles des données avant de séparer les machines
Commencez par distinguer quatre rôles : l’état applicatif faisant autorité, les données dérivées régénérables, l’espace de travail temporaire et les médias. La base de données, les utilisateurs, l’historique de visionnage, les listes de lecture, la configuration et les métadonnées sélectionnées font partie de l’ensemble à restaurer. Le cache et les segments de transcodage peuvent généralement être recréés. Les fichiers vidéo et musicaux sont de volumineux fichiers source dont la stratégie de protection peut être complètement différente de celle de la base de données de l’application.
Un guide actuel de maintenance des bases de données Jellyfin décrit la base de données unifiée de la version 10.11 comme un état opérationnel en temps réel plutôt qu’un cache jetable. C’est pourquoi le choix de l’emplacement des hôtes doit commencer par les exigences de propriété et de restauration, au lieu de placer tous les répertoires nommés « Jellyfin » sur le même partage.
Définissez ces rôles avant de choisir les hôtes. Si le serveur actuel dispose de suffisamment d’espace SSD et d’une couverture de sauvegarde suffisante pour l’état de l’application, aucun avantage architectural ne justifie de le déplacer. Si la bibliothèque multimédia a dépassé la capacité des baies locales, les limites d’alimentation ou de refroidissement, ou les possibilités d’isolation des pannes, ce rôle a une raison concrète d’être déplacé vers un NAS ou un serveur de stockage, tandis que l’application reste en local.
Conservez la base de données de production en local, sauf si l’utilisation d’une base externe est réellement prise en charge
Jellyfin 10.11 a achevé une migration majeure vers EF Core, mais cela ne fait pas d’un serveur PostgreSQL distinct la topologie de production par défaut. Des adaptateurs expérimentaux PostgreSQL existent, mais ils ajoutent un service, des identifiants, une compatibilité entre versions, un ordre de sauvegarde et une dépendance réseau supplémentaires. Pour un foyer ordinaire, ces coûts l’emportent sur l’élégance théorique d’un hôte de base de données dédié.
La version expérimentale de PostgreSQL indique elle-même que l’adaptateur est destiné à l’évaluation et non à un serveur prêt pour la production. Cette limite de la base de données expérimentale est un signal d’arrêt : ne fondez pas le plan de récupération de votre foyer sur un moteur non pris en charge simplement pour donner à la topologie un aspect plus professionnel.
En production, le stockage local ne signifie pas qu’il est sans protection. Placez l’état de l’application sur un stockage SSD fiable, sauvegardez-le vers un autre domaine de panne et vérifiez que la sauvegarde peut être restaurée avec la version de Jellyfin correspondante. Ne séparez le service de base de données que si le moteur choisi est pris en charge dans votre version, si vous pouvez l’exploiter indépendamment et si le gain en matière de récupération l’emporte sur les nouvelles dépendances au réseau et aux versions.
Déplacez les médias vers un hôte de stockage distinct lorsque la capacité ou la configuration des disques l’exige
Les médias volumineux ont un profil d’accès différent. La lecture directe lit principalement de gros fichiers de manière séquentielle, au débit de lecture correspondant. Un NAS peut donc diffuser les médias sans difficulté si le réseau, le montage et les disques prennent en charge le débit cumulé des flux. Séparer les médias permet aussi de garder un nœud de calcul compact, tandis que l’hôte de stockage peut évoluer avec des pools plus grands, davantage de baies ou une stratégie de sauvegarde différente.
Une récente configuration domestique avec Jellyfin conserve les données Docker sur SSD tandis que les médias sont sur HDD, illustrant une séparation entre applications sur SSD et médias sur HDD. Le compromis se remarque au début de la lecture : les disques durs en veille peuvent ajouter un délai de réveil, même si la navigation reste rapide grâce aux données de l’application stockées sur SSD.
Choisissez un hôte de stockage distinct si l’extension des disques, l’emplacement acoustique, la redondance ou le stockage partagé entre plusieurs services justifient ce chemin supplémentaire. Gardez les médias en local si un seul châssis répond déjà aux besoins de capacité et de sauvegarde. Séparer pour le principe ajoute du travail lié au DNS, aux montages, aux permissions, aux pannes réseau et à l’ordre de démarrage, sans changer le résultat pour l’utilisateur.
Considérez le réseau de stockage comme une dépendance essentielle, et non comme un câble invisible
Lorsque les médias sont hébergés ailleurs, Jellyfin dépend de la présence d’un montage avant les analyses et le fonctionnement normal. Un NAS indisponible peut laisser un point de montage vide qui ressemble toujours à un répertoire valide, tandis qu’un réseau lent ou instable peut transformer un problème de stockage en lecture différée. La topologie doit donc prévoir une règle de démarrage qui échoue de manière sécurisée et un objectif de bande passante mesurable.
L’expérience de la communauté montre que diffuser des médias depuis un NAS distinct sur un réseau domestique classique peut très bien fonctionner si le réseau est correctement dimensionné ; une discussion récente a révélé que de nombreux utilisateurs procédaient exactement ainsi sans problème de lecture. La leçon utile du stockage des médias sur un NAS distinct est que cette disposition réseau est viable, mais qu’elle doit être considérée comme faisant partie du chemin des médias et non comme une ressource gratuite.
Validez le segment le plus lent : pool de stockage, carte réseau du NAS, commutateur, carte réseau du serveur, protocole de montage et demande simultanée de flux. Arrêtez Jellyfin ou suspendez la maintenance destructive de la bibliothèque lorsque le montage média attendu est absent. Un deuxième hôte n’améliore la fiabilité que si sa panne est évidente et circonscrite, plutôt que de se traduire silencieusement par une bibliothèque vide.
Utilisez les tests de récupération et d’extension pour décider de la séparation
Avant d’ajouter un autre hôte, répétez deux scénarios : la perte du nœud de calcul Jellyfin et celle du nœud de stockage des médias. Un workflow de récupération axé sur la restauration testé montre pourquoi la configuration, les données persistantes, les définitions de services versionnées et l’ordre de restauration doivent être validés ensemble, plutôt que tenus pour acquis à la simple présence de fichiers de sauvegarde. Le test de l’hôte de stockage doit également garantir que Jellyfin se dégrade de façon prévisible, sans réécrire ni supprimer les données média faisant autorité.
L’audit de récupération du stockage Jellyfin de ZimaSpace applique le même test de responsabilité : chaque chemin persistant doit avoir un rôle nommé, une portée de sauvegarde et une méthode de restauration avant un incident.
Gardez un seul hôte si l’état de l’application, la capacité des médias, les sauvegardes et les E/S de pointe habituelles tiennent confortablement. Séparez le stockage des médias lorsque la capacité ou le cycle de vie du stockage devient une contrainte. Considérez un hôte de base de données distinct comme une exception avancée tant que le fournisseur de base de données n’est pas pris en charge en production et que sa récupération indépendante n’est pas possible. Le critère d’arrêt est une topologie dont vous pouvez nommer et restaurer les rôles, et non le nombre maximal de machines que vous pouvez ajouter.
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,...
