Comment désactiver Jellyfin sans laisser de données non protégées

Décommissionnez Jellyfin en supprimant son accès uniquement après avoir décidé de l’état à conserver, vérifié l’existence d’une sauvegarde récupérable et répertorié chaque chemin ou identifiant utilisé par le service. Supprimer d’abord le conteneur peut laisser derrière lui des montages de médias, des sauvegardes, des clés API, des routes de proxy inverse et des volumes persistants, même si l’interface Jellyfin a disparu.

Un retrait sûr poursuit deux objectifs : préserver tout ce dont vous pourriez avoir besoin ultérieurement et supprimer chaque voie susceptible d’exposer ou de modifier encore les données. Procédez de l’extérieur vers l’intérieur : désactivez les points d’entrée distants, arrêtez les nouvelles écritures, effectuez et testez la sauvegarde finale, supprimez l’application, puis examinez délibérément les volumes, les montages liés, le DNS, les règles du pare-feu et les identifiants. N’utilisez pas de commande générale de nettoyage avant de savoir quelles données persistantes ont été archivées ou volontairement détruites.

Répertoriez les données, les montages et les chemins d’accès avant la suppression

Répertoriez le répertoire de données et de configuration de Jellyfin, le cache, les montages de médias, le chemin de transcodage, le dossier de sauvegarde, le proxy inverse, le VPN ou tunnel, le nom DNS, les règles du pare-feu ainsi que les clés API et identifiants de service. Marquez chaque élément comme à conserver, à réutiliser, à renouveler ou à supprimer.

L’inventaire évite l’erreur courante qui consiste à considérer le conteneur de l’application comme l’intégralité du service. Sur un serveur domestique, les données importantes se trouvent souvent dans des montages liés ou des volumes nommés, tandis que le point d’entrée public se trouve dans une configuration de proxy ou DNS complètement différente.

Si le serveur était accessible à distance, examinez le même modèle de chemin que celui utilisé pour analyser les couches d’accès distant : le DNS public, le proxy ou VPN, le pare-feu et le service local constituent des couches distinctes, et chacune doit être retirée délibérément.

Créez une sauvegarde finale avant d’arrêter la dernière instance fonctionnelle

Effectuez une sauvegarde finale de Jellyfin tant que le serveur est encore dans un état connu et fonctionnel, puis copiez-la vers une destination qui survivra à la suppression de l’hôte ou des volumes Jellyfin. Indiquez dans le nom de l’archive la version de Jellyfin et la date de décommissionnement.

Les méthodes de sauvegarde officielles de Jellyfin décrivent les procédures intégrées et manuelles, et expliquent comment préserver l’état récupérable du serveur. Utilisez la méthode documentée correspondant à votre installation plutôt que de créer une copie à chaud incohérente des fichiers de base de données et de configuration.

Effectuez une petite validation de restauration ou, au minimum, inspectez le contenu de l’archive avant de continuer. Si la sauvegarde finale est incomplète, interrompez le décommissionnement et corrigez le problème tant que le serveur fonctionnel existe encore.

Désactivez l’accès externe avant de supprimer l’application

Supprimez ou désactivez les enregistrements DNS publics, les routes du proxy inverse, les redirections de ports, les partages de tunnel et les listes de contrôle d’accès VPN qui exposent spécifiquement Jellyfin. Cette étape ferme d’abord le chemin public, alors que le serveur reste disponible localement pour la vérification finale.

Depuis un réseau externe, vérifiez que l’ancienne URL publique de Jellyfin ou l’ancien tunnel n’atteint plus le service, puis confirmez que l’accès local fonctionne encore assez longtemps pour terminer la sauvegarde et l’inventaire. Ce test dans les deux sens prouve que vous avez fermé l’exposition sans détruire prématurément un état récupérable.

Renouvelez les clés API ou les identifiants dédiés à Jellyfin, en particulier s’ils étaient stockés dans des configurations de proxy, des scripts d’automatisation ou des systèmes de surveillance qui resteront après la suppression du service.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Supprimez les conteneurs et les volumes de manière réfléchie

Arrêtez et supprimez le conteneur Jellyfin uniquement après avoir vérifié la sauvegarde finale. Inspectez ensuite chaque montage lié et chaque volume nommé, puis déterminez s’il appartient exclusivement à Jellyfin ou s’il est partagé avec un autre service.

Docker précise que les volumes persistent après la suppression du conteneur ; supprimer un conteneur ne supprime pas automatiquement tous les volumes persistants. Cette persistance est utile pour la récupération, mais elle signifie aussi que des données d’application orphelines peuvent rester sur le disque jusqu’à ce que vous les traitiez explicitement.

N’exécutez pas docker volume prune comme première étape de nettoyage sur un hôte exécutant plusieurs applications. Supprimez uniquement les volumes que vous avez identifiés avec certitude et conservez l’archive finale en dehors du périmètre de ce nettoyage.

Vérifiez qu’aucune donnée Jellyfin non protégée ne subsiste

Recherchez sur l’hôte l’ancien chemin de données Jellyfin, les fichiers Compose restants, les fichiers d’environnement, les extraits de configuration du proxy, les archives de sauvegarde et les identifiants. Pour chaque élément restant, protégez-le selon votre politique habituelle de sauvegarde et d’accès, ou supprimez-le délibérément.

Vérifiez que les permissions des médias correspondent toujours aux services restants. Un utilisateur ou une ACL spécifique à Jellyfin peut ne plus être nécessaire, mais sa suppression ne doit pas perturber un autre conteneur qui partageait volontairement le même groupe ou le même montage de médias en lecture seule.

Le décommissionnement est terminé lorsque l’ancien chemin public est fermé, que la sauvegarde finale est récupérable, que l’application ne fonctionne plus et que chaque fichier ou identifiant restant possède un responsable explicite. Si vous ne pouvez pas rendre compte d’un volume ou d’une sauvegarde, mettez-le en quarantaine plutôt que de le supprimer aveuglément.