Comment éviter la perte de la configuration de Jellyfin lors des mises à niveau

Prévenez la perte de configuration de Jellyfin lors des mises à niveau en traitant l’état de l’application et l’environnement d’exécution remplaçable comme deux objets de récupération distincts.

Une mise à niveau peut réussir au niveau des paquets, tandis qu’un point de montage modifié, un identifiant utilisateur, une association de périphérique ou une migration peut donner à Jellyfin l’apparence d’une installation neuve. La prévention ne consiste pas simplement à « effectuer une sauvegarde » de manière abstraite : il faut savoir exactement où se trouve l’état, le capturer de façon cohérente, consigner la définition en cours d’exécution et vérifier que vous pouvez la restaurer.

Cartographiez les véritables chemins persistants avant la mise à niveau

Ne supposez pas que le chemin affiché dans un conteneur correspond au chemin hôte sauvegardé. Vérifiez le point de montage lié ou le volume nommé qui contient réellement la base de données, la configuration, les métadonnées et l’état des extensions.

Le stockage des conteneurs reste portable lorsque les définitions de volumes et les limites des services sont explicites dans la configuration du déploiement.

Notez le chemin hôte, le chemin du conteneur, les propriétaires et le système de fichiers pour chaque point de montage persistant. Si l’emplacement de l’état ne peut pas être identifié avec certitude, reportez la mise à niveau.

Effectuez une copie cohérente avant toute modification

Le point de récupération le plus utile est capturé avant que la nouvelle version puisse modifier la base de données. Une copie de fichiers effectuée pendant des écritures actives peut être moins fiable qu’une sauvegarde réalisée après l’arrêt du service ou qu’un instantané cohérent.

Une sauvegarde distincte de la configuration Jellyfin préserve l’état difficile à recréer, tout en laissant les contenus multimédias volumineux suivre leur propre stratégie de protection.

Créez la sauvegarde, stockez-la en dehors du périphérique de configuration actif et notez son horodatage ainsi que sa version. Une organisation persistante des données d’application doit vous permettre de sauvegarder l’état sans copier l’image elle-même.

Consignez la définition de l’environnement d’exécution avec autant de soin que les données

Une sauvegarde parfaite de la base de données ne restaurera pas l’accélération matérielle, les ports, le DNS, les périphériques ou les autorisations si la définition du conteneur recréé ne contient pas ces paramètres. Considérez la configuration Compose ou de la plateforme comme faisant partie de l’ensemble de récupération.

L’exécution des conteneurs avec une identité de service stable dépend d’une correspondance prévisible des UID et GID lors des mises à niveau et sur les systèmes de fichiers hôtes.

Exportez ou validez la définition effective du déploiement sans les secrets. Consignez le condensat de l’image et les associations de périphériques afin que le retour en arrière ne dépende pas de votre mémoire.

-15% OFF

ZimaBoard 2 - Mini serveur domestique pour votre grande idée

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Testez le processus de récupération avant de supprimer l’ancienne version

Le nettoyage doit avoir lieu après que la nouvelle version a résisté à un redémarrage et que la sauvegarde peut être localisée et ouverte. Si le retour en arrière n’a jamais été répété, la suppression des anciennes images et des instantanés élimine vos options de récupération les plus simples.

Un processus de restauration testé transforme une sauvegarde, jusque-là considérée comme une option de récupération, en une solution ayant effectivement permis de reconstruire un état d’application exploitable.

Validez les utilisateurs, les bibliothèques, les métadonnées, une lecture et un redémarrage. Conservez l’ensemble de récupération antérieur à la mise à niveau jusqu’à ce que la nouvelle version ait terminé les migrations prévues et ses tâches d’arrière-plan habituelles.