Jellyfin Data Paths Explained: What Must Persist and What Can Be Rebuilt
Jellyfin is safer to operate when database state, configuration, metadata, cache, temporary transcodes, and media are treated as different data roles.
Not every directory deserves the same storage tier or backup policy: user accounts and watch state must survive runtime replacement, while cache and transcode scratch can usually be rebuilt and media remains authoritative elsewhere. Mapping these roles prevents a container update or disk cleanup from becoming an accidental server reset. Define persistence by whether data must survive a clean runtime rebuild.
Database and Configuration Define the Server State
The database and configuration carry users, library definitions, preferences, watch state, and other identity-bearing data. Losing them can leave the media files intact while the server itself effectively starts over.
Jellyfin configuration state includes user accounts, library settings, watch history, and metadata that should be protected separately from the bulk media files.
Keep this state on a persistent path outside the replaceable image or package. A persistent app-data layout gives the runtime a stable place to reconnect after recreation.
Metadata Is Valuable but Not Identical to the Database
Artwork and generated metadata can be expensive to recreate at scale even when some source information is recoverable. Its recovery priority depends on how much manual curation and processing it contains.
Keeping container data on SSD while bulk media remains on HDD creates a clear SSD app-data and HDD media split, which separates browsing-state latency from high-capacity media storage.
Measure metadata size and rebuild cost before deciding whether it belongs in every backup tier. Treat hand-edited or hard-to-regenerate assets differently from disposable cache.
Cache and Transcode Scratch Should Have an Expiration Model
Cache and active transcode output exist to accelerate or support current work, not to define long-term server identity. Preserving them blindly increases backup size and can restore stale temporary state.
A media-server storage design separates local cache from durable media because high-churn temporary work has different latency and durability needs.
Place scratch on a fast path with explicit free-space monitoring. Verify the service can recreate it after deletion before excluding it from backup.
Media Should Remain a Separate Authoritative Tier
The library files may live on local disks or a NAS and can dwarf the application state by orders of magnitude. They need their own redundancy and backup decision rather than inheriting the database policy.
Backup capacity and churn vary by dataset, so one retention model rarely fits both app state and bulk media.
Document which path is authoritative for each role and test a restore where Jellyfin state reconnects to an unchanged media library. A clean role map makes future storage migrations much less ambiguous.
Recommended products
Tech & AI HUB
More to Read
Why Jellyfin Home-Server Architecture Changes as You Add Services
A Jellyfin box becomes a service stack as more apps are added, so CPU, storage, network, secrets, backups, and recovery boundaries need explicit ownership.
How to Measure Jellyfin Performance Without Mistaking Cache for Capacity
A reliable Jellyfin benchmark labels cold and warm state separately so cached metadata or filesystem pages are not mistaken for permanent hardware capacity.
How Much iGPU Headroom Does Multi-User Jellyfin Need?
Jellyfin iGPU headroom is workload-specific: reserve margin above the hardest repeatable concurrent transcode mix, not an arbitrary utilization percentage.
