Så förhindrar du att Jellyfin-konfigurationen går förlorad vid uppgraderingar

Eva Wong är Teknisk skribent och den boende fixaren på ZimaSpace. En livslång nörd med en passion för hemma-labb och öppen källkod, hon specialiserar sig på att översätta komplexa tekniska koncept till tillgängliga, praktiska guider. Eva tror att självhosting ska vara roligt, inte skrämmande. Genom sina handledningar ger hon gemenskapen verktyg att avmystifiera hårdvaruinstallationer, från att bygga sin första NAS till att bemästra Docker-containrar.

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.

-15% OFF
Single board computer zimaboard2

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

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.