Faut-il sauvegarder Jellyfin à chaud ou arrêter le service au préalable ?
Arrêtez Jellyfin pour une sauvegarde complète simple, sauf si votre méthode de capture instantanée peut préserver l’état de l’application de manière cohérente pendant que le service écrit.
Le compromis se situe entre indisponibilité et cohérence. Une archive créée lorsque le service est arrêté est facile à comprendre, car la base de données, la configuration et les métadonnées cessent de changer pendant la copie. Une sauvegarde à chaud peut être valide lorsque le mécanisme de sauvegarde de la base de données ou l’instantané du système de fichiers crée un point cohérent dans le temps, mais une copie récursive ordinaire pendant des écritures actives est plus difficile à considérer comme fiable.
Les copies effectuées service arrêté constituent la référence simple et sûre
Arrêter brièvement Jellyfin empêche les nouvelles écritures dans la base de données et les métadonnées pendant que l’outil de sauvegarde parcourt l’arborescence de configuration. Cela élimine de nombreuses questions de cohérence pour les petits serveurs domestiques.
Une copie de fichiers à chaud peut ignorer des transactions soutenues par le WAL ; les sauvegardes SQLite tenant compte des transactions évitent de copier une base de données ouverte comme s’il s’agissait d’un simple fichier statique.
Planifiez la pause pendant une période calme, vérifiez que le processus est arrêté, copiez les données persistantes, puis redémarrez le service. Mesurez l’interruption afin de connaître son coût opérationnel réel.
Les sauvegardes à chaud nécessitent un mécanisme d’instantané cohérent
Un instantané du système de fichiers peut figer la vue de nombreux fichiers à un instant donné, même si le service continue ensuite de fonctionner. C’est différent d’une copie lente des fichiers qui changent, effectuée un par un.
Les jeux de données actifs évoluent pendant la sauvegarde : la fréquence des changements compte donc lorsqu’une capture s’étend dans le temps.
Si vous utilisez ZFS, Btrfs ou une sauvegarde tenant compte de la base de données, documentez la garantie de cohérence fournie. Ne considérez pas une simple copie de fichiers à chaud comme équivalente sans l’avoir testée.
L’intégrité de la base de données compte davantage que la réussite de la sauvegarde
Une tâche de sauvegarde peut signaler sa réussite alors que la base de données capturée ne constitue pas un point de récupération exploitable. La vérification doit examiner conjointement la base de données et l’état de l’application.
Un ensemble de récupération fiable doit éviter les copies incontrôlées de la base de données pendant les écritures actives : la cohérence de SQLite dépend de la préservation d’un état cohérent de la base de données.
Restaurez la sauvegarde dans un chemin temporaire et lancez une vérification d’intégrité avant de vous y fier. La structure des données persistantes de l’application facilite ce test, car l’état est séparé du conteneur remplaçable.
Choisissez la méthode en fonction de votre objectif de récupération
Un foyer qui peut tolérer une fenêtre de maintenance de deux minutes tirera peut-être peu d’avantages d’une infrastructure complexe de sauvegarde à chaud. Un serveur soumis à des exigences strictes de disponibilité peut justifier l’utilisation d’instantanés, mais uniquement si les restaurations restent prévisibles.
Un test adéquat de reprise après sinistre mesure si la sauvegarde choisie permet réellement de remettre le service dans un état utilisable.
Comparez la durée d’indisponibilité pour la sauvegarde, le temps de restauration et la complexité des défaillances. Utilisez la méthode la plus simple qui répond à l’objectif de récupération du foyer et résiste à une véritable répétition de restauration.
Produits recommandés
Assistance et conseils
Plus à lire
Pourquoi Jellyfin chauffe-t-il ou est-il bruyant lorsque personne ne regarde de contenu en streaming ?
La chaleur au repos indique généralement une activité en arrière-plan ou une charge de travail d’hébergement partagé. Identifiez donc le processus actif et la...
Quand faut-il reconstruire Jellyfin plutôt que le réparer ?
Choisissez la reconstruction plutôt que la réparation lorsque la dérive de l’environnement d’exécution est à l’origine du problème et que l’état persistant est sauvegardé...
Quelle quantité de stockage libre Jellyfin doit-il conserver pour les tâches en arrière-plan ?
Aucun pourcentage universel d’espace libre ne convient à Jellyfin ; mesurez séparément la croissance persistante et les pics temporaires, puis prévoyez une marge supérieure...
