Avveckla Jellyfin genom att ta bort åtkomsten först när du har bestämt vilket tillstånd som ska bevaras, verifierat en återställningsbar säkerhetskopia och inventerat varje sökväg eller inloggningsuppgift som tjänsten använde. Om du tar bort containern först kan mediemonteringar, säkerhetskopior, API-nycklar, reverse proxy-rutter och beständiga volymer bli kvar, även om Jellyfin-gränssnittet har försvunnit.
En säker avveckling har två mål: bevara allt du kan behöva senare och ta bort varje väg som fortfarande kan exponera eller ändra data. Arbeta utifrån och in – inaktivera externa åtkomstvägar, stoppa nya skrivningar, skapa och testa den slutliga säkerhetskopian, ta bort programmet och granska sedan medvetet volymer, bindmonteringar, DNS, brandväggsregler och inloggningsuppgifter. Använd inte ett brett rensningskommando förrän du vet vilka beständiga data som har arkiverats eller avsiktligt förstörts.
Inventera data, monteringar och åtkomstvägar före borttagningen
Lista Jellyfins data- och konfigurationskatalog, cache, mediemonteringar, transkodningssökväg, säkerhetskopieringsmapp, reverse proxy, VPN eller tunnel, DNS-namn, brandväggsregler samt eventuella API-nycklar eller tjänsteinloggningar. Märk varje objekt som bevara, återanvänd, rotera eller ta bort.
Inventeringen förhindrar det vanliga misstaget vid avveckling att behandla programcontainern som hela tjänsten. På en hemmaserver finns det värdefulla tillståndet ofta i bindmonteringar eller namngivna volymer, medan den publika åtkomstpunkten finns i en helt separat proxy- eller DNS-konfiguration.
Om servern kunde nås på distans bör du granska samma lagerindelning som används när du spårar lager för fjärråtkomst: publik DNS, proxy/VPN, brandvägg och den lokala tjänsten är separata lager, och vart och ett måste avvecklas medvetet.
Skapa en slutlig säkerhetskopia innan du stoppar den sista fungerande instansen
Skapa en slutlig säkerhetskopia av Jellyfin medan servern fortfarande är i ett känt fungerande tillstånd och kopiera den sedan till en destination som överlever borttagningen av Jellyfin-värden eller volymerna. Märk arkivet med Jellyfin-versionen och avvecklingsdatumet.
Jellyfins officiella metoder för säkerhetskopiering beskriver både inbyggda och manuella metoder och förklarar hur du bevarar ett återställningsbart servertillstånd. Använd den dokumenterade metod som passar din installation i stället för att skapa en inkonsekvent livekopia av databas- och konfigurationsfiler.
Genomför en mindre återställningsvalidering eller inspektera åtminstone arkivets innehåll innan du fortsätter. Om den slutliga säkerhetskopian är ofullständig ska du avbryta avvecklingen och åtgärda den medan den fungerande servern fortfarande finns kvar.
Inaktivera extern åtkomst innan du tar bort programmet
Ta bort eller inaktivera publika DNS-poster, reverse proxy-rutter, portvidarebefordringar, tunneldelningar och VPN-åtkomstregler som specifikt exponerar Jellyfin. Genom att göra detta först stänger du den publika vägen medan servern fortfarande är tillgänglig lokalt för slutlig verifiering.
Bekräfta från ett externt nätverk att den gamla publika Jellyfin-URL:en eller tunneln inte längre når tjänsten och bekräfta sedan att lokal åtkomst fortfarande fungerar tillräckligt länge för att slutföra säkerhetskopieringen och inventeringen. Det här testet från båda sidor visar att du har stängt exponeringen utan att förstöra återställningsbart tillstånd i förtid.
Rotera API-nycklar eller inloggningsuppgifter som var avsedda enbart för Jellyfin, särskilt om de lagrades i proxykonfigurationer, automatiseringsskript eller övervakningssystem som blir kvar efter att tjänsten tagits bort.
Ta bort containrar och volymer med eftertanke
Stoppa och ta bort Jellyfin-containern först när den slutliga säkerhetskopian har verifierats. Inspektera sedan varje bindmontering och namngiven volym och avgör om den tillhör Jellyfin uteslutande eller delas med en annan tjänst.
Docker dokumenterar att volymer finns kvar efter att containern tagits bort; borttagning av en container tar inte automatiskt bort alla beständiga volymer. Det är praktiskt för återställning, men innebär också att överblivna programdata kan finnas kvar på disken tills du uttryckligen hanterar dem.
Kör inte docker volume prune som det första rensningssteget på en värd med flera program. Ta endast bort volymer som du med säkerhet har identifierat och förvara det slutliga arkivet utanför rensningens omfattning.
Verifiera att inget oskyddat Jellyfin-tillstånd finns kvar
Sök igenom värden efter den gamla Jellyfin-datasökvägen, kvarlämnade compose-filer, miljöfiler, proxyfragment, säkerhetskopieringsarkiv och inloggningsuppgifter. För varje kvarvarande objekt ska du antingen skydda det enligt din vanliga policy för säkerhetskopiering och åtkomst eller ta bort det avsiktligt.
Kontrollera att mediabehörigheterna fortfarande stämmer med de tjänster som finns kvar. En Jellyfin-specifik användare eller åtkomstkontrollista behövs kanske inte längre, men att ta bort den får inte bryta en annan container som avsiktligt delar samma grupp eller skrivskyddade mediemontering.
Avvecklingen är klar när den gamla publika vägen är stängd, den slutliga säkerhetskopian kan återställas, programmet inte längre körs och varje kvarvarande fil eller inloggningsuppgift har en uttrycklig ägare. Om du inte kan redogöra för en volym eller säkerhetskopia ska du sätta den i karantän i stället för att radera den blint.
Support och tips
Mer att läsa

Jellyfin fungerar via Wi-Fi men inte via Ethernet eller VPN
När Jellyfin bara fungerar via Wi‑Fi ska du isolera den förändrade nätverkssökvägen: destination, routing, brandväggens/lokal klassificering och därefter VPN-överlappning.

Bör du använda automatiska uppdateringar för Jellyfin på en hemmaserver?
Automatiska Jellyfin-uppdateringar är säkrast när säkerhetskopiering, versionsomfattning, återställning och validering efter uppdateringen är definierade innan den obevakade övergången.

Varför använder Jellyfin mycket CPU efter en uppdatering?
Hög CPU-användning efter en Jellyfin-uppdatering kan bero på tillfälliga uppgifter, omkodning, insticksprogram eller någon annan belastning. Isolera vad som utlöser det innan du åtgärdar...

