Så väljer du kapacitet för SSD, HDD och säkerhetskopiering för Jellyfin

Eva Wong

IceWhale author

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.

How to Choose SSD, HDD, and Backup Capacity for Jellyfin - Zima Store Online

Jellyfin-lagring bör dimensioneras som tre olika kapacitetsproblem: snabbt utrymme för applikationer och temporära filer, ekonomisk mediakapacitet samt oberoende återställningskapacitet. Om du köper en enda mycket stor enhet och kallar den ”Jellyfin-lagring” blir det svårare att förutsäga prestanda, tillväxt och återställning.

Börja med det aktuella biblioteket och den uppmätta mängden Jellyfin-data, lägg till den största tillfälliga arbetstoppen, prognostisera medietillväxten under den period du planerar att använda lagringen och dimensionera sedan säkerhetskopieringsgenerationer utanför den aktiva felzonen. Använd den tillgängliga kapaciteten efter redundans i stället för de råa siffrorna på enhetens etikett.

Dimensionera SSD:n för appdata och tillfälliga arbetstoppar

Jellyfins databas, metadata, omslagsbilder, loggar och andra applikationsfiler skapar slumpmässig I/O som gynnas av låg latens. Transkodningscachen skapar ett annat tillfälligt behov som kan öka kraftigt vid samtidiga konverteringar.

Den aktuella lagringsvägledningen för Jellyfin påpekar att en måttlig databas kan växa till tiotals gigabyte och att en transkodningsmapp tillfälligt kan närma sig storleken på källmediet som konverteras. Därför kan en liten start-SSD vara riskabel även när databasen fortfarande är liten.

Mät den aktuella storleken på appdata och den största verkliga transkodningstoppen. Lägg till marginal för ledigt utrymme för uppdateringar, temporära filer och tillväxt i stället för att fylla SSD:n till den angivna kapaciteten.

Dimensionera hårddiskkapaciteten utifrån medietillväxt och användbar redundans

Storskalig medielagring gynnas normalt av kapacitet och sekventiell genomströmning. Beräkna den aktuella mediestorleken, realistiska årliga tillägg och hur många år du förväntar dig att behålla lagringslayouten innan den byggs om.

Omvandla sedan den prognostiserade målstorleken till användbar kapacitet efter kostnaden för spegling eller paritet. Två 12 TB-enheter i en spegling ger inte 24 TB användbar mediekapacitet, och ögonblicksbilder eller reserverat ledigt utrymme kan ytterligare minska den kapacitet som bör betraktas som säker arbetskapacitet.

ZimaSpaces analys av Jellyfins lagringskostnad utöver mediefilerna förstärker uppdelningen: beständig appdata, genererade tillgångar, tillfälliga transkodningar och källmedia växer inte enligt samma kurva.

Köp mediakapacitet utifrån arbetsbelastningen, inte SSD-hastighet som standard

För stora filmer och avsnitt är sekventiell genomströmning vanligtvis viktigare än SSD-latens. Flera oberoende strömmar och samtidiga genomsökningar kan öka sökbelastningen, men en välfungerande hårddiskpool kan fortfarande leverera betydande mediebandbredd.

Välj enhetsmodeller och inspelningstekniker som passar kontinuerliga serverwrites och förutsägbart återuppbyggnadsbeteende. Flytta storskaliga medier till SSD endast när tyst drift, fysisk storlek, energiförbrukning eller uppmätt beteende vid blandad I/O motiverar den betydligt högre kostnaden per terabyte.

Medienivån bör väljas utifrån den sammanlagda bithastigheten och underhållsbelastningen, inte utifrån det generella påståendet att SSD alltid är snabbare.

Featured

ZimaCube 2 personlig molnhem NAS

ZimaCube2

Beräkna säkerhetskopieringskapacitet separat från RAID-kapacitet

RAID, speglingar, ZFS-redundans eller Btrfs-speglingar förbättrar tillgängligheten efter vissa enhetsfel, men de bevarar inte raderad metadata, skadat applikationstillstånd, en misslyckad uppgradering, ransomware-skador eller ett administratörsmisstag.

3-2-1-modellen rekommenderar flera kopior på olika medier, där minst en kopia finns på en annan plats. För Jellyfin bör du separat avgöra om oersättliga medier, ersättningsbara rippade medier och applikationstillstånd förtjänar samma säkerhetskopieringsdjup.

Säkerhetskopior av applikationstillstånd är små jämfört med ett mediearkiv på flera terabyte. Därför kan det vara ekonomiskt att ofta skydda användare, visningsförlopp, metadata och konfiguration även när hela mediebiblioteket har en annan säkerhetskopieringsstrategi.

Använd ett kapacitetsformulär innan du beställer enheter

Lagringsroll	Indata att mäta	Kapacitetsbeslut
SSD-appdata	Aktuella data + tillväxt	Beständig marginal med låg latens
SSD för transkodningscache	Största filen × samtidiga konverteringar	Tillfällig topp + marginal för ledigt utrymme
Hårddisk för medier	Aktuellt bibliotek + årlig tillväxt	Användbar kapacitet efter redundans
Lokal säkerhetskopia	Skyddad omfattning × sparade generationer	Oberoende kapacitet för återställning
Säkerhetskopia på annan plats	Oersättlig omfattning + lagringstid	Separat kopia för katastrofåterställning

Köp inte alla tre nivåerna utifrån samma tillväxttakt. Beräkna på nytt efter att du aktiverat trickplay, ändrat lagringstiden för säkerhetskopior, lagt till 4K-remuxer eller gått från mestadels Direct Play till frekvent transkodning.

Vanliga frågor

Bör hela Jellyfins mediebibliotek ligga på SSD?

Vanligtvis inte. SSD är mest värdefullt för Jellyfins appdata och temporära sökintensiva I/O-sökvägar. Hårddiskar är fortfarande kostnadseffektiva för stora sekventiella medieläsningar när den sammanlagda genomströmningen och sökbeteendet motsvarar den faktiska strömmixen.

Hur mycket säkerhetskopieringsutrymme behöver Jellyfin?

Det beror på vad du skyddar och hur många återställningspunkter du sparar. Dimensionera säkerhetskopian av applikationstillstånd separat från mediearkivet och multiplicera sedan den skyddade omfattningen med en realistisk lagringstid i stället för att kopiera lagringspoolens råa storlek.