Jellyfin-gegevenspaden uitgelegd: wat behouden moet blijven en wat opnieuw kan worden opgebouwd
Jellyfin is veiliger in gebruik wanneer de databasestatus, configuratie, metadata, cache, tijdelijke transcodes en media als verschillende datarollen worden behandeld.
Niet elke map verdient dezelfde opslaglaag of hetzelfde back-upbeleid: gebruikersaccounts en kijkstatus moeten een vervanging van de runtime overleven, terwijl cache en transcodebestanden doorgaans opnieuw kunnen worden opgebouwd en media elders de bron van waarheid blijft. Door deze rollen in kaart te brengen, voorkom je dat een containerupdate of schijfopruiming per ongeluk leidt tot een serverreset. Bepaal de persistentie op basis van de vraag of gegevens een schone herbouw van de runtime moeten overleven.
De database en configuratie bepalen de serverstatus
De database en configuratie bevatten gebruikers, bibliotheekdefinities, voorkeuren, kijkstatus en andere identiteitsgebonden gegevens. Als deze verloren gaan, kunnen de mediabestanden intact blijven terwijl de server zelf in feite opnieuw begint.
De configuratiestatus van Jellyfin omvat gebruikersaccounts, bibliotheekinstellingen, kijkgeschiedenis en metadata, die afzonderlijk van de omvangrijke mediabestanden moeten worden beschermd.
Bewaar deze status op een persistent pad buiten de vervangbare image of het pakket. Een persistente indeling voor app-gegevens geeft de runtime een stabiele locatie om na het opnieuw aanmaken weer verbinding te maken.
Metadata is waardevol, maar niet hetzelfde als de database
Illustraties en gegenereerde metadata kunnen op grote schaal veel tijd kosten om opnieuw te maken, zelfs wanneer bepaalde broninformatie kan worden hersteld. De herstelprioriteit hangt af van de hoeveelheid handmatige samenstelling en verwerking die erin zit.
Door containergegevens op een SSD te bewaren terwijl bulkmedia op een HDD blijft staan, ontstaat een duidelijke scheiding tussen app-gegevens op SSD en media op HDD. Hierdoor wordt de latentie van de bladerstatus gescheiden van opslag met hoge capaciteit voor media.
Meet de omvang van de metadata en de kosten voor het opnieuw opbouwen voordat je bepaalt of deze in elke back-uplaag thuishoort. Behandel handmatig bewerkte of moeilijk opnieuw te genereren bestanden anders dan wegwerpbare cache.
Cache en tijdelijke transcodebestanden moeten een vervalmodel hebben
Cache en actieve transcode-uitvoer bestaan om huidig werk te versnellen of te ondersteunen, niet om de identiteit van de server op lange termijn te bepalen. Ze blind bewaren vergroot de omvang van back-ups en kan verouderde tijdelijke status herstellen.
Een opslagontwerp voor een mediaserver scheidt lokale cache van duurzame media, omdat tijdelijke gegevens met veel wijzigingen andere vereisten hebben op het gebied van latentie en duurzaamheid.
Plaats tijdelijke bestanden op een snel pad en monitor expliciet de beschikbare ruimte. Controleer of de service deze bestanden na verwijdering opnieuw kan aanmaken voordat je ze uitsluit van back-ups.
Media moet een afzonderlijke gezaghebbende laag blijven
De bibliotheekbestanden kunnen op lokale schijven of een NAS staan en de applicatiestatus met meerdere ordes van grootte overtreffen. Ze hebben hun eigen beslissing over redundantie en back-ups nodig, in plaats van automatisch het databasebeleid te volgen.
De capaciteit en veranderingssnelheid van back-ups verschillen per dataset, waardoor één bewaarmodel zelden geschikt is voor zowel applicatiestatus als bulkmedia.
Documenteer welk pad voor elke rol de bron van waarheid is en test een herstel waarbij de Jellyfin-status opnieuw verbinding maakt met een ongewijzigde mediabibliotheek. Een duidelijke rolindeling maakt toekomstige opslagmigraties veel minder onduidelijk.
Aanbevolen producten
Tech & AI HUB
Meer om te lezen
Waarom de architectuur van je Jellyfin-thuisserver verandert naarmate je meer services toevoegt
Een Jellyfin-box wordt een dienstenstack naarmate er meer apps worden toegevoegd. Daarom moeten CPU, opslag, netwerk, geheimen, back-ups en herstelgrenzen expliciet worden toegewezen.
Jellyfin-prestaties meten zonder cache met capaciteit te verwarren
Een betrouwbare Jellyfin-benchmark labelt de koude en warme toestand afzonderlijk, zodat metadata uit de cache of bestandssysteempagina’s niet wordt aangezien voor permanente hardwarecapaciteit.
Hoeveel iGPU-capaciteit heeft Jellyfin nodig voor meerdere gebruikers?
De iGPU-reservecapaciteit van Jellyfin is werkbelastingsspecifiek: houd marge boven de zwaarste herhaalbare combinatie van gelijktijdige transcoderingen aan, in plaats van een willekeurig gebruikspercentage.
