Förhindra att Jellyfin-konfigurationen förloras under uppgraderingar genom att behandla applikationens tillstånd och den utbytbara körtidsmiljön som två separata återställningsobjekt.
En uppgradering kan lyckas på paketnivå samtidigt som en ändrad montering, ett användar-ID, en enhetsmappning eller en migrering får Jellyfin att se ut som en ny installation. Förebygg detta genom att veta exakt var tillståndet finns, säkerhetskopiera det konsekvent, dokumentera den körande definitionen och bevisa att du kan återställa den.
Kartlägg de verkliga beständiga sökvägarna före uppgraderingen
Anta inte att sökvägen som visas inuti en container är värdsökvägen som säkerhetskopieras. Kontrollera bind-monteringen eller den namngivna volymen som faktiskt innehåller databas-, konfigurations-, metadata- och plugin-tillstånd.
Containerlagring förblir portabel när volymdefinitioner och tjänstegränser är tydligt angivna i distributionskonfigurationen.
Skriv ned värdsökväg, containersökväg, ägarskap och filsystem för varje beständig montering. Om det inte går att identifiera tillståndets plats med säkerhet bör du skjuta upp uppgraderingen.
Skapa en konsekvent kopia före ändringen
Den mest användbara återställningspunkten är en som skapats innan den nya versionen kan ändra databasen. En filkopia som tas under aktiva skrivningar kan vara svårare att lita på än en säkerhetskopiering när tjänsten är stoppad eller en sammanhängande ögonblicksbild.
En separat säkerhetskopia av Jellyfin-konfigurationen bevarar det tillstånd som är svårt att återskapa, medan omfattande mediefiler kan skyddas via sin egen säkerhetskopieringsväg.
Skapa säkerhetskopian, lagra den utanför den aktiva konfigurationsenheten och notera tidsstämpel och version. En beständig layout för appdata bör göra det möjligt att säkerhetskopiera tillståndet utan att kopiera själva avbildningen.
Dokumentera körtidsdefinitionen lika noggrant som data
En perfekt databassäkerhetskopia återställer inte maskinvaruacceleration, portar, DNS, enheter eller behörigheter om den återskapade containerdefinitionen saknar dessa inställningar. Behandla Compose- eller plattformskonfigurationen som en del av återställningsuppsättningen.
Att köra containrar med en stabil tjänsteidentitet är beroende av förutsägbar UID- och GID-mappning mellan uppgraderingar och värdfilsystem.
Exportera eller versionshantera den effektiva distributionsdefinitionen utan hemligheter. Dokumentera avbildningens digest och enhetsmappningar så att en återställning inte är beroende av minnet.
Testa återställningsvägen innan du tar bort den gamla versionen
Rensa först när den nya versionen har överlevt en omstart och säkerhetskopian kan hittas och öppnas. Om återställning aldrig har övats tar borttagning av gamla avbildningar och ögonblicksbilder bort dina billigaste återställningsalternativ.
En testad återställningsväg förvandlar en säkerhetskopia från ett antaget återställningsalternativ till något som faktiskt har återskapat ett användbart applikationstillstånd.
Kontrollera användare, bibliotek, metadata, en uppspelning och en omstart. Behåll återställningsuppsättningen från före uppgraderingen tills den nya versionen har slutfört sina förväntade migreringar och normala bakgrundsarbete.
Support och tips
Mer att läsa

Bör du säkerhetskopiera Jellyfin medan tjänsten körs eller stoppa tjänsten först?
Föredra säkerhetskopior av stoppade tjänster för enkelhetens skull; använd live-ögonblicksbilder endast när applikationstillståndet fångas konsekvent och återställningar har testats.

Varför blir Jellyfin varmt eller högljutt när ingen streamar?
Värme vid inaktivitet beror vanligtvis på bakgrundsarbete eller en belastning från en delad värd, så identifiera den aktiva processen och den schemalagda uppgiften innan...

När bör du bygga om i stället för att reparera Jellyfin?
Välj ominstallation framför reparation när problemet är avvikelser i körmiljön och beständiga data är säkerhetskopierade; ”ominstallera” inte genom att radera den enda fungerande databasen.

