Comment empêcher les sauvegardes de Jellyfin de capturer un état incohérent

Eva Wong est la rédactrice technique et bricoleuse résidente chez ZimaSpace. Geek depuis toujours, passionnée par les homelabs et les logiciels open source, elle se spécialise dans la traduction de concepts techniques complexes en guides accessibles et pratiques. Eva croit que l’auto-hébergement doit être amusant, pas intimidant. À travers ses tutoriels, elle donne à la communauté les moyens de démystifier les configurations matérielles, depuis la construction de leur premier NAS jusqu’à la maîtrise des conteneurs Docker.

Une sauvegarde Jellyfin peut contenir tous les fichiers tout en restant incohérente si la base de données, la configuration et les métadonnées changent pendant la capture. Il faut donc définir la limite d’écriture avant de choisir un outil de sauvegarde.

Pour un serveur domestique, la routine la plus sûre consiste à mettre Jellyfin au repos ou à utiliser un instantané du système de fichiers couvrant tous les chemins contenant des données d’état, à ne relancer la source qu’une fois la capture terminée, puis à tester la restauration d’une copie. Si le test révèle des utilisateurs ou un historique manquants, conservez la dernière sauvegarde connue comme étant correcte au lieu de la remplacer.

Définissez la limite de cohérence avant l’exécution de la tâche

Les sauvegardes s’exécutent selon un calendrier, avec un moment d’écriture inconnu. Commencez par la vérification la moins invasive : répertoriez les tâches Jellyfin actives et déterminez si la sauvegarde arrête le service, suspend les écritures ou crée un instantané atomique de tous les chemins contenant des données d’état. limite de restauration

L’observation utile doit être précise : le service peut être arrêté brièvement, le système de fichiers prend en charge les instantanés, ou aucune de ces limites n’est disponible. Notez le résultat avant de modifier une autre variable.

Interprétez le scénario au lieu de deviner. Si un arrêt ou un instantané coordonné est possible, planifiez-le ; sinon, utilisez la sauvegarde de l’application et documentez son périmètre ; si aucune de ces options n’est possible, ne considérez pas une copie de fichiers effectuée à chaud comme vérifiée.

Capturez tous les chemins contenant des données d’état dans cette limite

La limite de capture est sélectionnée. Commencez par la vérification la moins invasive : comparez le manifeste de sauvegarde aux chemins de données, de configuration et de cache de Jellyfin, ainsi qu’à la définition des points de montage du conteneur ou de l’hôte.

L’observation utile doit être précise : tous les chemins requis sont inclus, seul le cache manque, ou la configuration ou la base de données est absente. Notez le résultat avant de modifier une autre variable. inventaire des chemins d’état

Interprétez le scénario au lieu de deviner. Si les données et la configuration sont incluses, continuez ; si seul le cache manque, indiquez qu’il peut être reconstruit ; si la base de données ou la configuration est absente, rejetez la sauvegarde et corrigez le manifeste.

Testez la restauration d’une copie avant de faire confiance à la rétention

Une sauvegarde a été capturée dans la limite sélectionnée. Commencez par la vérification la moins invasive : restaurez-la vers un chemin de données distinct, démarrez la version correspondante de Jellyfin, connectez-vous, vérifiez l’historique et les bibliothèques, puis lisez un élément.

L’observation utile doit être précise : l’état est cohérent, l’assistant de configuration apparaît, ou une bibliothèque ou un utilisateur manque. Notez le résultat avant de modifier une autre variable.

Interprétez le scénario au lieu de deviner. Si l’état et la lecture sont corrects, acceptez la sauvegarde ; si l’assistant de configuration apparaît, le montage est incorrect ; si l’état est manquant, rejetez la sauvegarde et conservez la copie précédente.

Gérez une sauvegarde suspecte avec l’étape de récupération la plus simple

Un test de restauration révèle un état manquant ou incohérent. Commencez par la vérification la moins invasive : conservez la sauvegarde suspecte en lecture seule, comparez-la à la dernière copie acceptée et examinez les journaux de la source avant de relancer la capture.

L’observation utile doit être précise : la source est saine, la source est déjà endommagée, ou un seul chemin diffère. Notez le résultat avant de modifier une autre variable. rétention testée après restauration

Interprétez le scénario au lieu de deviner. Si la source est saine, corrigez la limite ou le manifeste, puis relancez la capture ; si la source est endommagée, restaurez d’abord la dernière bonne copie ; si un seul chemin diffère, réparez ce montage et répétez le test.

Assistance et conseils

Plus à lire

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.