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

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

Följ checklistan i beroendeordning. Kontrollera först 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 omstartsbeteende innan du raderar återställningskopian.

Dokumentera den senast fungerande avbildningen och containerdefinitionen

Spara den aktuella avbildningstaggen för Jellyfin och, när det är praktiskt möjligt, 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 kopplingar till en omvänd proxy.

Den officiella dokumentationen för Jellyfin-containrar skiljer mellan flytande taggar som latest och uttryckliga taggar för större, mindre och korrigerande versioner. Så fungerar taggar för Jellyfin-avbildningar Det är enklare att återställa 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 den beständiga datan påverkas ger den sparade 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 applikationssökvägen och kunna läsas oberoende av den. En andra kopia eller ögonblicksbild på samma dataset är bara användbar om du förstår vilka fel den skyddar mot.

Jellyfins säkerhetskopieringsdokumentation varnar för att uppgraderingar kan kräva att data återställs, eftersom det inte finns någon generell nedgraderingsmekanism när migreringar väl har genomförts. Den dokumenterar även inbyggda säkerhetskopior och kravet på en ren avstängning vid manuell kopiering av filer. Jellyfins vägledning för säkerhetskopiering och återställning

För containerarbetsflöden täcks samma princip av ZimaSpaces arbetsflöde för återställningspunkt före uppdatering. Avbryt här om du inte kan identifiera de beständiga sökvägarna eller verifiera innehållet i säkerhetskopian.

Dokumentera monteringar, UID/GID och hårdvaruberoenden

Lista alla bindmonteringar och namngivna volymer och ange om de är skrivskyddade eller skrivbara. Notera körningens UID/GID, gruppmedlemskap och ägarskapet för Jellyfins datakataloger. Dokumentera också GPU- eller renderingsenhetsmappningar om hårdvaruacceleration ä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 De här värdena är beroenden, inte dekoration: en återskapad container kan starta utan problem men ändå se en tom konfigurationskatalog eller sakna behörighet till en enhet.

Jämför den sparade definitionen med den faktiskt körande containern, inte bara med en mall som du tror är aktuell. Om det finns manuella ändringar i körmiljön som saknas i Compose- eller NAS-appdefinitionen, åtgärda skillnaderna före uppgraderingen så att den gamla driftsättningen går att återskapa.

Featured

ZimaCube 2 personlig moln-NAS för hemmet

ZimaCube2

$799.00 - $2,499.00

Buy Now

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

Läs versionsinformationen för varje större versionsgräns mellan den aktuella versionen och målversionen. Kontrollera om det krävs mellanversioner, databasmigreringar, ändrad konfiguration, kompatibilitet med insticksprogram, FFmpeg-krav eller långvariga startprocesser.

Jellyfins uppgraderingsdokumentation betonar upprepade gånger 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 versioner kan lägga till versionsspecifika förutsättningar, så dra inte slutsatsen att det går att hoppa över versioner säkert bara för att containeravbildningen finns.

Om ett insticksprogram är nödvändigt ska du bekräfta att en kompatibel version finns tillgänglig innan du uppgraderar servern. Om ett insticksprogram är valfritt och tidigare har hindrat uppstarten ska du anteckna den aktuella versionen och vara beredd att inaktivera enbart det insticksprogrammet om den nya serverns loggar pekar ut det som felkällan.

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

Stoppa Jellyfin på ett ordnat sätt, hämta den avsedda avbildningen och återskapa endast Jellyfin-tjänsten med samma verifierade beständiga sökvägar och körningsberoenden. Kombinera inte uppgraderingen med en lagringsmigrering, omarbetning av UID/GID, omskrivning av omvänd proxy och omkonfigurering av GPU, såvida inte dessa ändringar är det egentliga syftet med underhållet.

Håll uppsikt över den första startloggen. En migrering kan med rätta 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å ett annat problem. Starta inte om en migrering upprepade gånger bara för att grä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 oftast att den nya tjänsten pekar på fel beständiga tillstånd. Korrigera monteringsmappningen först; konfigurering av en ny, tom instans kan skapa filer som försvårar återställningen.

Verifiera den nya versionen innan du tar bort återställningsresurserna

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

Starta om containern en gång efter den första lyckade sessionen. Den nya versionen är inte helt verifierad förrän den kan öppna samma data och enheter efter en ren återskapning eller omstart. Då upptäcks oavsiktligt beroende av tillfälliga monteringar eller körningstillstånd.

Behåll säkerhetskopian från före uppgraderingen, referensen till den tidigare avbildningen och den sparade definitionen tills servern har passerat sin normala arbetsbelastningsperiod. Om en återställning krävs efter en databasmigrering 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.