Conservez l’état de Plex qui définit le serveur et la bibliothèque : considérez le cache temporaire et les données de transcodage comme pouvant être recréés, sauf si votre stratégie de récupération l’exige autrement.
L’essentiel est la récupérabilité, pas la taille des dossiers. La configuration, les bases de données, les métadonnées, les illustrations, les références à l’état de visionnage et l’identité du serveur sont difficiles ou fastidieuses à recréer de manière cohérente, tandis que les fichiers temporaires de transcodage et de nombreux éléments du cache peuvent être régénérés. Classez chaque chemin selon ce qui se passerait après sa suppression avant de décider où le placer.
L’état du serveur ne se résume pas à un fichier de paramètres
Un déploiement Plex est défini par un ensemble de fichiers persistants, et pas uniquement par les préférences visibles dans l’interface web. La base de données de la bibliothèque et les répertoires de métadonnées contiennent les relations et l’état du serveur qui permettent à une instance restaurée de ressembler à l’ancienne.
Le stockage des métadonnées de Plex comprend les bases de données, les illustrations, les index et d’autres fichiers liés à l’état du serveur.
Répertoriez tous les chemins Plex montés et indiquez ceux qui seraient nécessaires pour recréer les mêmes bibliothèques et métadonnées sur un hôte vierge. Si un chemin contient l’état de la base de données ou des métadonnées du serveur, incluez-le dans l’ensemble des sauvegardes persistantes. Conserver les données persistantes des conteneurs en dehors de l’environnement d’exécution remplaçable aide à séparer les couches recréables de l’état qui doit survivre au remplacement du conteneur.
Le cache est précieux, mais généralement reconstituable
Le cache peut réduire la latence sans constituer la copie de référence de la bibliothèque. La perte d’un cache préchauffé peut ralentir le serveur pendant un certain temps, mais elle ne doit pas être traitée comme la perte de la base de données.
La mise en cache des pages Linux peut réduire les accès répétés au stockage une fois les données chargées en mémoire.
Redémarrez une instance de test après avoir supprimé uniquement le cache jetable identifié, puis comparez son comportement pendant la phase de préchauffage à celui du serveur intact. Si le serveur perd l’identité de la bibliothèque ou ses paramètres, le chemin supprimé n’était pas un simple cache jetable.
L’intégrité de la base de données modifie la priorité de sauvegarde
Les données persistantes ne sont utiles que si la base de données sauvegardée est cohérente en interne. Une base de données copiée pendant des écritures peut être moins fiable qu’une sauvegarde produite durant une période d’activité contrôlée.
La sécurité des écritures SQLite privilégie les écritures contrôlées : la base de données Plex active ne doit donc pas servir de test de permissions.
Planifiez une fenêtre de sauvegarde pendant laquelle les écritures sont suspendues ou arrêtées lorsque cela est possible, puis vérifiez que la base de données copiée peut être ouverte. Si le test de restauration échoue alors que les fichiers ont bien été copiés, corrigez la cohérence de la sauvegarde avant d’augmenter la durée de conservation.
L’espace temporaire de transcodage relève d’une autre classe de récupération
La sortie du transcodage est une donnée de travail créée pour un chemin de lecture, et non la bibliothèque de référence. Elle peut être placée en fonction de la vitesse et de la capacité disponibles, sans imposer la même politique de durabilité que la base de données Plex.
Lorsque le transcodage Plex est nécessaire, la compatibilité du client déplace le décodage et l’encodage vers le serveur.
Documentez séparément les montages du transcodage et du cache, ainsi que le montage des données Plex persistantes, dans votre fichier de déploiement. Si un chemin temporaire est le seul endroit où se trouve un paramètre ou un fichier de base de données unique, reclassez-le avant la prochaine migration.
Centre Tech & IA
Plus à lire

Why Jellyfin Home-Server Architecture Changes as You Add Services
A Jellyfin box becomes a service stack as more apps are added, so CPU, storage, network, secrets, backups, and recovery boundaries need explicit ownership.

How to Measure Jellyfin Performance Without Mistaking Cache for Capacity
A reliable Jellyfin benchmark labels cold and warm state separately so cached metadata or filesystem pages are not mistaken for permanent hardware capacity.

How Much iGPU Headroom Does Multi-User Jellyfin Need?
Jellyfin iGPU headroom is workload-specific: reserve margin above the hardest repeatable concurrent transcode mix, not an arbitrary utilization percentage.

