En checklista inför uppgradering av Jellyfin-containrar och beroenden

Innan du uppgraderar en Jellyfin-container bör du bevara båda delarna av driftsättningen: Jellyfins beständiga tillstånd och den exakta containerdefinition som vet hur den ska nå det. En ny avbildning är enkel att hämta; att återställa en migrerad databas, en ändrad montering eller en bortglömd enhetsmappning är det inte.

Använd checklistan i beroendeordning. Börja med att bevisa att du kan återställa data, dokumentera sedan den aktuella avbildningen och körtidsinställningarna, läs därefter uppgraderingsvägen och byt först sedan ut avbildningen. Testa efteråt samma bibliotek, användare, uppspelningslägen, schemalagda uppgifter och omstarts­beteende innan du tar bort återställningskopian.

Dokumentera den senast fungerande avbildningen och containerdefinitionen

Spara den aktuella Jellyfin-avbildningens tagg och, när det är praktiskt möjligt, även dess digest. Exportera eller kopiera Compose-filen eller appdefinitionen som innehåller portar, nätverk, monteringar, miljövärden, omstartspolicy, användarmappning, kompletterande grupper, GPU-enheter och eventuella relationer till en omvänd proxy.

Jellyfins officiella dokumentation för containers skiljer mellan flyttbara taggar som latest och uttryckliga taggar för huvud-, del- och korrigeringsversioner. Jellyfins beteende för avbildningstaggar En återställning blir enklare när du känner till den exakta fungerande versionen i stället för att bara minnas att ”latest fungerade i går”.

Rensa inte bort den gamla avbildningen och ta inte bort den sparade definitionen förrän den nya versionen har klarat hela valideringsperioden. Om uppgraderingen misslyckas innan beständiga data har berörts ger den bevarade avbildningen och definitionen dig den minst ingripande återställningsvägen.

Skapa en återställningsbar säkerhetskopia av Jellyfins tillstånd

Skydda Jellyfins data- och konfigurationskataloger innan avbildningen ändras. Säkerhetskopian måste finnas utanför den aktiva programsökvägen och kunna läsas fristående. En andra kopia eller ögonblicksbild på samma datamängd är bara användbar om du förstår vilket fel den skyddar mot.

Jellyfins dokumentation om säkerhetskopiering varnar för att uppgraderingar kan kräva att data återställs, eftersom det saknas en generell nedgraderingsmekanism efter att migreringar har tillämpats. Den dokumenterar också inbyggda säkerhetskopior och kravet på ren avstängning vid manuella filkopior. Jellyfins vägledning för säkerhetskopiering och återställning

För ett containerbaserat arbetsflöde täcks samma princip av ZimaSpaces arbetsflöde för återställningspunkt före uppdatering. Stanna här om du inte kan identifiera de beständiga sökvägarna eller verifiera säkerhetskopians innehåll.

Samla in monteringar, UID/GID och maskinvaruberoenden

Lista varje bindmontering och namngiven volym och ange om den är skrivskyddad eller skrivbar. Dokumentera UID/GID för körtiden, gruppmedlemskapen och ägarskapet för datakataloger som ägs av Jellyfin. Samla även in mappningar för GPU eller renderingsenheter om maskinvaruacceleration är aktiverad.

Jellyfins containerguide visar att media, konfiguration och cache monteras separat och att containern kan köras med ett angivet UID/GID. beständiga sökvägar och användarmappning Dessa värden är beroenden, inte dekoration: en återskapad container kan starta utan problem men ändå se en tom konfigurationskatalog eller förlora behörigheten till en enhet.

Jämför den sparade definitionen med den effektiva containern som körs, inte bara med en mall som du tror är aktuell. Om körtidsmiljön har manuella ändringar som saknas i Compose eller NAS-appens definition bör du rätta till denna avvikelse före uppgraderingen, så att den gamla driftsättningen går att återskapa.

Featured

ZimaCube 2 personlig molnhem NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Kontrollera den stödda uppgraderingsvägen och risken med insticksprogram

Läs versionsinformationen för varje större versionsgräns mellan den aktuella versionen och målversionen. Leta efter nödvändiga mellanversioner, databas­migreringar, ändrad konfiguration, kompatibilitet för insticksprogram, FFmpeg-krav eller långvarigt arbete vid uppstart.

Jellyfins uppgraderingsdokumentation betonar upprepade gånger vikten av säkerhetskopior och förklarar varför schemaändringar kan göra en enkel nedgradering omöjlig. gränser för uppgradering och nedgradering Versionsinformation för större utgåvor kan lägga till versionsspecifika förkrav, så anta inte att ett hopp är säkert bara för att containeravbildningen finns.

Om ett insticksprogram är nödvändigt bör du bekräfta att en kompatibel version finns innan serveruppgraderingen. Om ett insticksprogram är valfritt och tidigare har blockerat uppstarter bör du dokumentera dess aktuella version och vara beredd att endast inaktivera det insticksprogrammet om den nya serverns loggar identifierar det som felkällan.

Genomför uppgraderingen utan att ändra tillståndsgränsen

Stoppa Jellyfin korrekt, hämta den avsedda avbildningen och återskapa endast Jellyfin-tjänsten med samma verifierade beständiga sökvägar och körtidsberoenden. Kombinera inte uppgraderingen med en lagringsmigrering, en omarbetning av UID/GID, en omskrivning av den omvända proxyn och en omkonfigurering av GPU:n, om inte dessa ändringar faktiskt är underhållsarbetets syfte.

Följ den första uppstartsloggen. En migrering kan legitimt ta tid för ett stort bibliotek, medan ett omedelbart meddelande om ”permission denied”, tom databas, saknad sökväg eller inkompatibelt schema pekar på en annan felgren. Starta inte om en migrering upprepade gånger bara för att användargränssnittet inte blir tillgängligt direkt.

Om containern öppnas som en ny server ska du stoppa den innan du konfigurerar något. Det symptomet betyder vanligtvis att den nya tjänsten pekar på fel beständiga tillstånd. Rätta monteringsmappningen först; om du konfigurerar en ny tom instans kan nya filer skapas som försvårar återställningen.

Validera den nya versionen innan du tar bort återställningstillgångarna

Verifiera den ursprungliga serveridentiteten, användarna, biblioteken, metadata och viktiga inställningar. Spela upp ett objekt med direktuppspelning och en representativ transkodning, och kör eller observera sedan en schemalagd uppgift som är viktig för din konfiguration. Kontrollera loggarna efter återkommande migrerings-, databas-, behörighets- och FFmpeg-fel.

Starta om containern en gång efter den första lyckade sessionen. Den nya versionen är inte fullt validerad förrän den kan öppna samma data och enheter efter ett rent återskapande eller en omstart. Detta upptäcker oavsiktligt beroende av en tillfällig montering eller körtidstillstånd.

Behåll säkerhetskopian före uppgraderingen, referensen till den tidigare avbildningen och den sparade definitionen tills servern har klarat sitt normala arbetsbelastningsfönster. Om en återställning krävs efter en databas­migrering ska du följa Jellyfins dokumenterade återställningsgräns i stället för att rikta en äldre avbildning mot ett redan migrerat tillstånd.