Plex Configuration vs Cache vs User Data: What Actually Needs to Persist?
Persist the Plex state that defines the server and library; treat temporary cache and transcode data as rebuildable unless your recovery design requires otherwise.
The key is recoverability, not folder size. Configuration, databases, metadata, artwork, watch-state references, and server identity are difficult or tedious to recreate consistently, while temporary transcode files and many cache artifacts can be regenerated. Classify each path by what would happen after deletion before deciding where it belongs.
Server State Is More Than a Settings File
A Plex deployment is defined by a group of persistent files, not only by the visible preferences in the web interface. The library database and metadata directories carry relationships and server state that make a restored instance look like the old one.
Plex metadata storage includes databases, artwork, indexes, and other server-state files.
List every mounted Plex path and mark which ones would be required to reproduce the same libraries and metadata on a clean host. If a path contains server database or metadata state, include it in the persistent backup set. Keeping persistent container data outside the replaceable runtime helps separate rebuildable layers from state that must survive container replacement.
Cache Is Valuable but Usually Reconstructable
Cache can reduce latency without being the canonical copy of the library. Losing warm cache may make the server feel slower for a while, but it should not be treated the same as losing the database.
Linux page caching can reduce repeated storage access once data warms in memory.
Restart a test instance with only known disposable cache cleared and compare warm-up behavior to the intact server. If the server loses library identity or settings, the removed path was not merely disposable cache.
Database Integrity Changes the Backup Priority
Persistent data is only useful if the captured database is internally consistent. A copied database taken during writes can be harder to trust than a backup produced during a controlled quiet state.
SQLite write safety favors controlled writes, so the live Plex database should not be used as a permission probe.
Schedule a backup window that quiesces or stops the writer when practical, then verify the copied database can be opened. When the restore test fails even though the files copied successfully, fix backup consistency before increasing retention.
Temporary Transcode Space Belongs in a Different Recovery Class
Transcode output is working data created for a playback path, not the authoritative library. It can be placed for speed and capacity without forcing the same durability policy as the Plex database.
When Plex transcoding is required, client compatibility shifts decoding and encoding work onto the server.
Document transcode and cache mounts separately from the persistent Plex data mount in your deployment file. If a temporary path is the only place a unique setting or database file exists, reclassify it before the next migration.
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.
