Så utformar du säkerhetskopiering, återställning och utökning av Jellyfin från dag ett

Eva Wong är teknisk skribent och händig hemmabyggare på ZimaSpace. Som tekniknörd sedan barnsben med ett brinnande intresse för hemlabb och programvara med öppen källkodspecialiserar hon sig på att göra komplexa tekniska koncept begripliga genom praktiska, praktiska guider. Eva tycker att självhosting ska vara roligt, inte avskräckande. Genom sina handledningar hjälper hon communityn att göra hårdvaruinstallationer mindre mystiska, från att bygga sin första NAS till att bemästra Docker-containrar.

Utforma Jellyfin med sex separata roller: uppstart, applikationstillstånd, media, cache, säkerhetskopia och återställning. Utöka sedan bara den roll som närmar sig sin gräns.

En liten installation kan ha flera roller på samma maskin, men deras livscykler bör inte suddas ut. Håll ändringsbart tillstånd lätt att ta ögonblicksbilder av, media bakom stabila logiska sökvägar, cache förbrukningsbar och minst en återställningskopia utanför den aktiva felzonen. Verifiera utformningen genom att återställa till ett rent mål innan du automatiserar lagringstider eller lägger till diskar.

Kartlägg sex dataroller innan du väljer diskar

Utgå från vad du vill uppnå, inte från diskfacken. Uppstarts- och körmiljöfiler ska gå att återskapa; Jellyfins databas, inställningar, användare, visningshistorik och kurerade metadata är beständigt tillstånd; media är omfattande användardata; transkodningar och bildcache går att återskapa; säkerhetskopior är återställningsunderlag; och återställningsmålet är platsen där du verifierar underlaget.

Den här uppdelningen förebygger två kostsamma misstag: att säkerhetskopiera terabyte av kasserbar cache lika ofta som en databas som ändras, eller att skydda databasen samtidigt som oersättliga hemmafilmer saknar en andra kopia. Den fristående guiden för återställning med Ubuntu och Docker skiljer också mellan beständig konfiguration och cache som kan återskapas.
Roll Typiskt innehåll Designregel
Uppstart/system Operativsystem, paket, körmiljödefinition Dokumentera eller avbilda det; utgå från att det går att återskapa
Applikationstillstånd Databas, användare, inställningar, metadata Snabb lokal lagring plus samordnade säkerhetskopior
Användarmedia Filmer, musik, familjefiler Stabila sökvägar och separat skyddspolicy
Cache Transkodningar, ändrade bildstorlekar, tillfälligt arbete Placera här för genomströmning; tillåt återskapande
Säkerhetskopia Versionshanterade återställningskopior Håll utanför den aktiva felzonen
Återställning Ren testvärd eller isolerat namnrymdsutrymme Använd det för att bevisa återställning, inte för produktionslagring

Stanna här om något plugin, certifikat, undertext eller anpassat tillgång fortfarande saknar en ansvarig. En oklassificerad beständig sökväg blir den fil som upptäcks först när den ursprungliga servern är borta.

Håll tillstånd lokalt och mediesökvägar stabila

Placera applikationens tillstånd på tillförlitlig lokal SSD-lagring med övervakad ledig kapacitet. Montera media separat på logiska sökvägar som klarar byten av disk, kabinett eller lagringspool. Jellyfin-tjänsten ska se samma sökväg före och efter utökningen, även om det underliggande lagret ändras.

Betrakta cache som en resurs för genomströmning, inte som ett återställningsberoende. Vid lätt belastning kan den ligga på systemets SSD eller flyttas till en särskild snabb volym när skrivningar, kapacitet eller slitage blir mätbara problem. Flytta inte databasen och cachen tillsammans bara för att båda är små.

Kräv före varje start att media- och tillståndsmonteringarna finns och är skrivbara för körningsidentiteten. En saknad nätverksmontering som i tysthet blir en tom lokal katalog kan leda till skanningar eller skrivningar mot fel sökväg. Den relaterade guiden om återställning av behörigheter och identitet beskriver ägargränsen efter ändrade sökvägar.

Utforma säkerhetskopieringen kring återställningsobjekt

Säkerhetskopiera programtillståndet som ett enda sammanhängande återställningsobjekt. För den enklaste installationen stoppar du Jellyfin under det korta kopieringsfönstret; lagringsögonblicksbilder fungerar bara om de fångar alla tillståndskomponenter vid en och samma återställningsbara tidpunkt. Anteckna Jellyfin-versionen intill varje kontrollpunkt, eftersom en databasmigrering kan göra en oöverlagd nedgradering av avbildningen osäker.

Skydda media med en annan frekvens. Köpta medier kan kanske hämtas från källan igen; familjeinspelningar kanske inte kan det. Klassificera dessa delmängder innan du väljer replikering, offlinekopior eller lagring på annan plats. Guiden om lagringstid och återställningsfönster är nästa steg för att avgöra hur många tillståndsgenerationer du ska behålla.

Minst en användbar kopia måste överleva om den aktiva värden och dess anslutna lagring går förlorade eller skadas. En speglad pool ökar tillgängligheten vid ett enhetsfel, men en synkroniserad radering eller databaskorruption kan påverka alla speglar; redundans och säkerhetskopiering skyddar mot olika typer av fel.

Testa en ren återställning innan automatisering

Återställ till en isolerad maskin, virtuell maskin eller container med samma Jellyfin-version som skapade kontrollpunkten. Återskapa körningsidentiteten och de logiska monteringspunkterna, starta utan att exponera den nya servern för produktionsklienter och bekräfta sedan en administratörsinloggning, användarhistorik, antal bibliotek, omslagsbilder, ett objekt med Direct Play och en representativ transkodning.

Poängen är inte att instrumentpanelen laddas. Ett aktuellt fall med TrueNAS-migrering visar hur programtillstånd, chartutgåvor och en ny containeranslutning kan kollidera; en ren testkörning blottlägger beroendena medan den gamla instansen fortfarande finns kvar.
  1. Dokumentera källversion, körningsidentitet, monteringskarta och kontrollsumma för säkerhetskopian.
  2. Återställ tillståndet till ett rent, isolerat mål.
  3. Verifiera användare, bibliotek, metadata och representativ uppspelning.
  4. Starta om en gång och upprepa grundkontrollerna.
  5. Ta tiden på proceduren och uppdatera körboken med varje manuellt beroende.

Underkänn övningen om den kräver en odokumenterad hemlighet, omskrivning av sökvägar eller en livefil från produktionen. Automatisering kommer först efter att den här manuella sekvensen har lyckats två gånger, inte före.

Utöka kapaciteten utan att byta namn på bibliotek

Välj en utökningströskel som ger tillräckligt med tid för att kopiera och validera data utan akut tidspress. En varaktig användning på omkring tre fjärdedelar av den användbara poolen är en signal för planering, inte en universell regel; använd din inmatningstakt, återuppbyggnadstid, säkerhetskopieringstid och historik över varningar om ledigt utrymme för att fastställa den faktiska gränsen.

Utöka bakom den befintliga logiska mediesökvägen när det är möjligt. Förbered den nya enheten eller poolen, kontrollera hälsa och skrivbeteende, kopiera i stället för att flytta den första representativa uppsättningen, jämför antal eller hashvärden och testa en biblioteksskanning och uppspelning innan den nya kapaciteten börjar användas för vanliga skrivningar.

Om utökningen också kräver ett nytt filsystem, en ny värd, ett nytt delningsprotokoll eller en ny monteringssökväg ska den delas upp i separata ändringar. Topologin för beräkning, lagring och säkerhetskopiering hjälper dig att avgöra när kapacitetstillväxt motiverar att roller separeras i stället för att en enda enhet byggs ut.

Validera hela topologin och dess begränsningar

Kör designen som ett system: kallstart efter en kontrollerad avstängning, start med ett beroende otillgängligt, fyll en testvolym till dess varningströskel, återställ en tillståndskontrollpunkt och läs medier från den utökade sökvägen. Dokumentera vad som stängs säkert, vad som fungerar sämre och vad som kräver åtgärder av operatören.

Kör flera roller på samma värd så länge deras sammanlagda belastning, kabeldragning, strömförbrukning och återställningstid håller sig inom dina mål. Dela upp medielagring, säkerhetskopiering eller återställning först när en uppmätt gräns för kapacitet, underhåll eller felområde visar sig; fler maskiner skapar egna beroenden för nätverk och livscykel.

Den sista regeln är enkel: bevara stabila logiska sökvägar, skydda tillstånd som inte kan återskapas separat och bevisa att återställningen fungerar efter varje topologiförändring. Kapacitet som inte går att återställa är inte färdig kapacitet.

Installation av NAS och server

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.