Sauvegardes intégrées de Jellyfin ou sauvegardes au niveau des fichiers : laquelle devriez-vous utiliser ?

Les sauvegardes Jellyfin intégrées et les sauvegardes au niveau des fichiers protègent des périmètres de récupération qui se chevauchent, mais qui restent différents. Le système intégré comprend les données de l’application Jellyfin et peut créer une archive pendant que le serveur reste en ligne. Une sauvegarde manuelle au niveau des fichiers peut capturer un état de déploiement plus large, mais Jellyfin doit être arrêté avant de copier en toute sécurité ses données d’application actives.

La meilleure stratégie n’est souvent pas de choisir l’une ou l’autre. Utilisez la méthode intégrée pour créer fréquemment des points de récupération de l’application, et une méthode au niveau des fichiers ou du système de fichiers lorsque vous devez reproduire les chemins de l’hôte, la configuration, les définitions de conteneurs ou un état plus large du serveur.

Les sauvegardes intégrées sont idéales pour les points de récupération en ligne courants

Le système de sauvegarde Jellyfin actuel peut protéger la base de données et inclure facultativement les métadonnées, les sous-titres et les données de trickplay pendant que le serveur fonctionne. Cela facilite la création de points de récupération planifiés sans interrompre volontairement la lecture habituelle.

La documentation de sauvegarde de Jellyfin indique que les sauvegardes intégrées peuvent s’exécuter en ligne, tandis que les sauvegardes manuelles du répertoire de données nécessitent l’arrêt du serveur. Même la méthode en ligne doit idéalement être exécutée pendant une période de faible activité, sans analyse de bibliothèque simultanée.

C’est le meilleur choix par défaut lorsque l’objectif de récupération est de « ramener cette instance Jellyfin à un état applicatif connu ».

Les sauvegardes au niveau des fichiers sont préférables lorsque la récupération inclut la structure de l’hôte

Une copie au niveau des fichiers peut inclure les dossiers d’application persistants, les fichiers Compose, les fichiers d’environnement, la configuration du proxy inverse, les unités de service, les scripts, les certificats et autres éléments de déploiement qu’une archive limitée à Jellyfin ne connaît pas automatiquement.

Ce périmètre plus large est utile en cas de défaillance du disque système ou de migration vers un hôte de remplacement. Le compromis concerne la cohérence : les outils ordinaires de copie de fichiers ne comprennent pas une base de données SQLite en cours de modification. Arrêtez donc proprement Jellyfin avant de copier son état persistant actif.

Le guide ZimaSpace consacré aux structures de stockage Jellyfin présentant un risque pour la récupération souligne le même problème : une sauvegarde est incomplète si personne ne peut reproduire les chemins, les montages, les autorisations et les dépendances externes nécessaires au serveur restauré.

Une sauvegarde prenant en compte la base de données diffère de la copie d’un fichier SQLite actif

SQLite permet d’effectuer une sauvegarde en ligne cohérente au moyen d’interfaces prenant en compte la base de données, mais un outil de copie générique qui lit les fichiers pendant que Jellyfin les modifie ne bénéficie pas automatiquement de la même garantie.

L’API de sauvegarde SQLite est conçue pour copier une base de données active vers une destination cohérente au moyen d’opérations coordonnées sur la base de données. C’est pourquoi le fait que « les fichiers aient été copiés sans erreur » ne suffit pas à prouver la fiabilité d’une sauvegarde manuelle en ligne de Jellyfin.

Si votre méthode manuelle se limite à rsync, une copie SMB, un fichier zip ou une copie générique du système de fichiers, arrêtez d’abord Jellyfin, sauf si l’instantané du stockage est coordonné avec les écritures de l’application.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Comparez le périmètre avant de comparer la simplicité

Conservez la sauvegarde en dehors du domaine de défaillance de Jellyfin actif

Aucune des deux méthodes ne protège contre la perte du pool lorsque toutes les sauvegardes se trouvent sur le même système de fichiers défaillant. Copiez les archives de sauvegarde vérifiées ou les ensembles de récupération réalisés après arrêt vers un autre disque, un NAS ou un emplacement hors site.

Conservez au moins un point antérieur à chaque mise à niveau, car Jellyfin applique des migrations de données au démarrage d’une version plus récente et ne fournit pas de procédure générale de rétrogradation sur place.

Testez les deux styles de restauration s’ils font tous deux partie du plan de récupération. Une archive intégrée valide la récupération de l’application ; un test au niveau des fichiers vérifie que l’environnement peut recréer les chemins persistants et les autorisations associées.

FAQ

Dois-je arrêter Jellyfin avant d’utiliser la sauvegarde intégrée ?

Non. La méthode intégrée est conçue pour fonctionner pendant l’exécution de Jellyfin, même si une faible activité et l’absence d’analyse de bibliothèque en cours sont recommandées. Arrêtez le serveur pour effectuer une copie manuelle ordinaire des données Jellyfin actives.

La sauvegarde intégrée peut-elle remplacer ma sauvegarde de l’hôte ?

Pas toujours. Elle protège l’état de l’application Jellyfin, mais une récupération complète de l’hôte peut également dépendre des fichiers Compose, des paramètres du proxy, des certificats, des montages, des autorisations, des scripts et d’autres éléments de configuration externes.