Så separerar du Jellyfins appdata, cache och säkerhetskopior
Separera Jellyfins appdata, cache och säkerhetskopior genom att fråga vad som måste överleva en ominstallation, vad som kan återskapas och vad som måste vara tillgängligt efter att enheten med det aktiva tillståndet har gått sönder. Dessa tre roller kan dela en fysisk SSD i en liten server, men de bör inte dela samma livscykel eller återställningspolicy.
Beständig applikationsstatus omfattar databasen, konfigurationen, användar- och uppspelningsstatus samt andra filer som krävs för att återställa samma server. Cache och transkodningsarbete kan kasseras när ingen aktiv uppgift längre behöver dem. Säkerhetskopior är återställningskopior och bör inte vara beroende av samma lagringsgräns som de är avsedda att återställa.
Gör beständig appdata till den auktoritativa tillståndsrollen
Börja med att kartlägga värdsökvägen eller volymen som innehåller Jellyfins beständiga tillstånd. I en containerdistribution kan avbildningen ersättas; det monterade tillståndet måste anslutas igen när containern återskapas. Dokumentera värdsökväg, containersökväg, ägarskap, filsystem, gräns för ledigt utrymme och säkerhetskopieringsmetod.
En aktuell Jellyfin-layout för Docker Compose separerar beständiga konfigurations- och cachekataloger innan media monteras. Denna sökvägsskillnad är praktiskt användbar även när båda katalogerna till en början ligger på samma SSD.
Placera inte den auktoritativa databasen på en plats som du kan tänka dig att rensa under felsökning. En lyckad cacherensning ska aldrig kunna återställa användare, bibliotek, visningsstatus eller serveridentitet.
Behandla cache- och transkodningsutrymme som återskapningsbar arbetsdata
Cache finns för att minska upprepat arbete eller lagra tillfälliga bearbetningsresultat. Dess värde ligger i prestanda och bekvämlighet, inte i identitet. Ge den tillräcklig kapacitet för de största normala topparna vid bakgrundsarbete och transkodning, men se till att den kan återskapas utan att hela servern behöver återställas.
Förhindra att cache- eller transkodningsaktivitet med hög förändringstakt styr säkerhetskopieringspolicyn för databasen. Om samma snabba enhet innehåller båda rollerna bör du använda separata kataloger eller datamängder med separata kvoter och separat övervakning. Det förhindrar att en tillfällig topp förbrukar det lediga utrymme som behövs för databasskrivningar eller en framtida återställning.
När bläddring, metadata och tillståndsåtgärder känns långsamma medan sekventiella medieläsningar fortfarande fungerar bra, erbjuder ZimaSpaces analys av interaktivt tillstånd för medieservrar på SSD ett användbart nästa test, utan att behandla mediebiblioteket i stort som samma lagringsarbetsbelastning.
Containern kan kasseras; tillståndet och återskapandereceptet kan inte det
En container kan hämtas igen, men du kan inte utgå från att dess distributionsrecept och beständiga data återkommer. Spara Compose- eller tjänstedefinitionen, policy för avbildningsversion eller tagg, monteringskarta, tjänsteidentitet, referenser till nödvändiga hemligheter samt det beständiga Jellyfin-tillståndet.
Den praktiska regeln i detta arbetsflöde för säkerhetskopiering av Docker-volymer är att användbara återställningsdata finns i volymer, bindmonteringar, appdata och tjänstedefinitioner, inte i själva den kasserbara containern.
För aktiva databaser är konsekvens viktigare än att kopiera varje byte medan tjänsten är upptagen. Använd applikationens stödda säkerhetskopieringsväg eller en kontrollerad stopp-/ögonblicksbildsmetod som passar distributionen, i stället för att behandla en godtycklig kopia av aktiva filer som en bevisat återställningsbar tidpunkt.
En säkerhetskopia bredvid det aktiva tillståndet skyddar inte mot värdfel
En säkerhetskopia bredvid den aktiva databasen kan hjälpa vid oavsiktliga ändringar, men den överlever inte alla pool-, värd-, utpressningsprogram-, stöld- eller strömrelaterade händelser som kan slå ut produktionen. Förvara en återställningskopia på en annan enhet eller inom en annan administrativ gräns och skydda de nycklar eller autentiseringsuppgifter som krävs för att läsa den.
En säkerhetskopieringsplan för självhosting bör koppla samman tillstånd, hemligheter, återställningskopior och återställningsinstruktioner. Denna återställningsgranskning för självhosting betonar kopior utanför den uppenbara skadezonen och dokumenterade indata för ominstallation, i stället för att räkna ögonblicksbilder som en komplett plan.
Låt inte säkerhetskopieringsmålet omfattas av samma regel för cachelagring eller samma rensningskommando som den aktiva app-poolen. Säkerhetskopian är en separat roll även om den tillfälligt lagras i samma chassi.
Kartlägg lagringsrollerna innan du köper eller flyttar enheter
| Roll | Exempel | Kan återskapas? | Primär policy |
|---|---|---|---|
| Beständigt apptillstånd | Databas, konfiguration, användare, visningsstatus, pluginer/inställningar | Inte utan stora kostnader | Låg latens, ledigt utrymme, konsekvent säkerhetskopiering |
| Cache/tillfälligt | Cache, tillfälligt transkodningsutrymme, kasserbara mellanresultat | Ja | Kapacitet, prestanda, begränsad rensning |
| Säkerhetskopia | Versionshanterad tillståndskopia, distributionsrecept, återställningsmetadata | Nej; den är återställningskällan | Oberoende feldomän, lagringstid, återställningstest |
| Media | Filmer, serier, familjevideor | Beror på källan | Kapacitet och separat skyddspolicy |
Denna karta förhindrar ett vanligt misstag vid omdesign: att flytta allt till den snabbaste disken när det bara var appens tillståndslatens som var ett problem, eller att säkerhetskopiera varje tillfällig fil men utelämna tjänstedefinitionen som krävs för att återskapa containern.
Bevisa separationen med en tillfällig återställning
Återställ Jellyfin-tillståndet till en ny sökväg eller en isolerad värd, rikta en kopierad distributionsdefinition mot den platsen, ge icke-förstörande åtkomst till representativa medier och starta tjänsten utan den ursprungliga cachen. Servern ska återkomma med förväntad identitet, bibliotek, användare och inställningar även om cachen börjar tom.
Skillnaden blir mätbar först när en säkerhetskopia återställs till ett isolerat mål och verifieras utan att låna produktionens tillstånd. Testinstansen av Jellyfin ska starta från återställningskopian, ansluta sina nödvändiga sökvägar igen och bevisa att den aktiva volymen inte i hemlighet slutför återställningen.
Layouten klarar testet när cachen kan raderas utan att identiteten går förlorad, körmiljön kan återskapas utan att biblioteket behöver byggas upp från minnet och minst en säkerhetskopia kan återställa tjänsten efter att enheten med den aktiva appdatan antas vara otillgänglig.
Rekommenderade produkter
NAS- och serverinstallation
Mer att läsa
Hur AI-liknande analys och automatisering förändrar Jellyfins behov av lagring och beräkningskapacitet
Automatisering och närliggande AI-analys tillför skanningar, härledda data, CPU-/GPU-bearbetning, cache, arbetsutrymme och bakgrunds schemaläggning utöver vanlig uppspelning i Jellyfin.
Så integrerar du Jellyfin i ett litet lägenhets- eller hyresnätverk
Bygg ett hyresvänligt Jellyfin-nätverk med stabil lokal adressering, minimalt med kabeldragning, tyst hårdvara, fjärråtkomst anpassad för CGNAT och ändringar som enkelt kan återställas.
Hur många användare och bakgrundsjobb bör en Jellyfin-värd stödja?
Behandla Jellyfin-användare och bakgrundsjobb som en gemensam arbetsbelastningsbudget; kapaciteten är slut när uppspelningslatens, köer eller resursbelastning återkommande når gränsen.
