Comment réparer Jellyfin après le remplissage de son volume de base de données

Lorsque le volume de la base de données de Jellyfin est plein, arrêtez les nouvelles écritures, préservez la base de données et les fichiers WAL, libérez de l’espace en toute sécurité, puis validez la base de données avant de reprendre les tâches normales.

Jellyfin ne démarre-t-il plus, signale-t-il des erreurs SQLite ou s’ouvre-t-il avec des utilisateurs manquants après que le volume a atteint zéro octet disponible ? Ne supprimez pas immédiatement les fichiers de la base de données et n’exécutez pas de tâches de nettoyage. Commencez par noter le volume, l’espace disponible, les noms des fichiers de base de données, l’état du conteneur et la dernière sauvegarde connue comme valide.

Empêcher l’échec de se transformer en tempête d’écritures

Arrêtez Jellyfin ainsi que tout importateur, analyseur ou service auxiliaire qui écrit sur le même volume. Vérifiez quel point de montage est plein, y compris les inodes, et préservez la base de données principale ainsi que les fichiers associés `-wal` ou `-shm`. Un disque plein peut laisser des fichiers de configuration vides ou partiellement écrits ; un incident dépendant de la version montre que libérer de l’espace ne suffit pas toujours à rétablir le démarrage (cas de récupération après saturation du volume).

Libérez de l’espace en supprimant les journaux jetables, les fichiers de transcodage terminés ou le cache connu comme pouvant être régénéré, mais seulement après avoir copié l’état persistant. Ne supprimez jamais la base de données en première étape.

Notez la taille de la base de données, les fichiers WAL, les journaux, le cache et l’espace libre restant avant le nettoyage. Cela permet de déterminer si le volume a été rempli par la croissance de la base de données, la sortie de transcodage, les journaux ou un autre conteneur.

Vérifier l’intégrité de la base de données avant toute tentative de réparation

Travaillez sur une copie de la base de données pendant que Jellyfin reste arrêté. Exécutez une vérification d’intégrité avec les outils SQLite disponibles dans votre environnement et examinez les journaux à la recherche d’erreurs telles que « disk full », image malformée ou impossibilité d’ouvrir le fichier. Si la vérification réussit, rétablissez un espace libre suffisant, redémarrez une fois, puis vérifiez les utilisateurs, les bibliothèques et la lecture.

Si la base de données est malformée, restaurez d’abord la dernière sauvegarde connue comme valide. Une procédure de récupération contrôlée peut utiliser les outils de récupération SQLite sur une copie, mais elle ne remplace pas une sauvegarde validée et ne doit pas être effectuée sur une base de données active (procédure de récupération basée sur une copie).

Après avoir libéré uniquement les données pouvant être régénérées, confirmez que les fichiers de la base de données sont toujours réunis et lisibles. Un redémarrage avant cette vérification peut transformer une écriture incomplète en un second échec.

Éviter que le volume n’atteigne à nouveau cette limite

Déplacez le cache et la sortie de transcodage vers un chemin surveillé, configurez des alertes au-dessus du seuil minimal d’espace libre et vérifiez la conservation des journaux ainsi que les planifications d’analyse. Séparez l’état de l’application des médias volumineux afin qu’une bibliothèque en croissance ne puisse pas saturer le volume de la base de données.

Redémarrez deux fois, exécutez l’analyse ou la lecture d’origine et confirmez que la sauvegarde suivante se termine correctement. Faites remonter le problème lorsque les vérifications d’intégrité échouent, que la base de données ne peut pas être restaurée ou que le volume se remplit à nouveau sans processus responsable visible.

Si la vérification d’intégrité réussit, redémarrez une fois et exécutez la charge de travail d’origine des utilisateurs et des bibliothèques. Si elle échoue, travaillez à partir d’une copie ou restaurez la base de données au lieu d’ouvrir à répétition la base endommagée.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Valider la récupération et éviter une nouvelle saturation du volume

Effectuez un redémarrage à froid, une analyse, une session de lecture et une sauvegarde après la réparation. Confirmez que le volume de la base de données conserve une marge d’espace libre surveillée pendant l’activité de la charge de travail.

Conservez la réparation lorsque les utilisateurs, les bibliothèques, les tâches planifiées et la lecture fonctionnent tous à nouveau. Ajoutez des alertes pour l’espace et les inodes, puis déplacez le cache ou les journaux vers un emplacement qui ne peut pas saturer le volume de la base de données.

Faites remonter le problème lorsque le volume se remplit à nouveau sans processus responsable visible, que les vérifications d’intégrité échouent ou que la base de données restaurée perd des utilisateurs ou son état.