What Immich Data Must Persist, and Why Do the Storage Roles Matter?
Immich reliability depends on keeping authoritative originals and application state persistent while treating regenerable derivatives and temporary work as different storage roles.
Putting every directory on one volume can work, but it hides which data must survive a rebuild, which data can be recreated, and which data should remain independent as a backup. That distinction controls recovery time, storage placement, and the safety of cleanup operations more than the directory names themselves.
Original Media Is the Irreplaceable Content Role
Uploaded photos and videos are the household memories the application exists to preserve. Their storage path may vary with deployment and storage-template choices, but their role is stable: they are source assets, not a cache, and losing them cannot be repaired by regenerating thumbnails or search indexes.
A current self-hosting overview that separates media and database placement is useful because it frames storage as a reliability design rather than a single capacity number. Treat its hardware suggestions as examples, while preserving the more general distinction between bulk originals and active application state.
Do not classify a directory by how easy it is to recreate the container. Containers and application images are replaceable; the mounted media they reference may not be. Before any cleanup or migration, identify the canonical original location and verify that an independent copy exists.
PostgreSQL Is the Authoritative Relationship Role
The database preserves the applicationโs understanding of users, assets, paths, albums, sharing, metadata, settings, and search-related state. A folder full of photos is therefore not equivalent to a restored Immich instance: the filesystem and database describe different parts of the same library.
The service architecture makes this dependency visible by separating PostgreSQL from media storage and background processing. That separation explains why database latency can affect interaction and why a media-only backup cannot preserve every application relationship.
The failure boundary is important: a database dump alone is also not a photo backup. It can restore metadata and relationships only when the corresponding media files are present at the expected logical state. Protect both sides and test them together.
Generated Media Trades Storage for Faster Use
Thumbnails, previews, and compatible video encodes exist to make browsing and playback practical without repeatedly processing full originals. They may consume substantial space, but their recovery value differs because many can be regenerated if the originals and required application state survive.
A home-lab example with separate storage roles shows why operators often place active database work and bulk photo storage differently. The point is not that every home needs the same disks, but that generated high-churn data can have a different performance and backup policy from originals.
Regenerable does not mean free. Rebuilding derivatives for a large family library can consume hours or days of CPU, storage I/O, and queue time. Excluding them from backup is a recovery-time decision, not proof that they are operationally worthless.
Queues and Caches Are Not a Durable Source of Truth
Queue state and caches help the running system coordinate and accelerate work, but they should not become the only place where an irreplaceable fact exists. If a transient queue disappears after restart, durable database and filesystem state should still allow the application to determine what needs to happen next.
The ZimaSpace article on the Immich data path is useful for separating persistent state from the services that move requests through the system. A queue explains work-in-progress; it should not be mistaken for the household archive itself.
This model stops being safe if a custom integration stores unique state only in a temporary path, an unbacked container layer, or an undocumented sidecar location. Inventory custom mounts and overrides before assuming the default persistence categories cover the whole deployment.
Build a Recovery Matrix Before Moving Storage
List each roleโoriginals, profiles, database, generated thumbnails, encoded video, model cache, backups, configuration, and any external libraries. For each, record its host path, whether it is authoritative, whether it can be regenerated, its maximum acceptable loss, and the expected restore time.
ZimaSpaceโs family photo backup guide provides the right operational boundary: a usable family service requires protected media plus the application state needed to make that media coherent after a failure.
Accept the persistence design only when a fresh host can restore representative originals, accounts and relationships, and then regenerate any deliberately excluded derivatives. If recovery depends on remembering an undocumented volume or recovering a container writable layer, the storage roles are not yet safely defined.
Recommended products
Tech & AI HUB
More to Read
Open Models Are Catching Frontier AIโIs 2026 the Year Local AI Becomes Good Enough?
Open models are getting good enough for more local AI workloads, while frontier cloud models remain useful for the hardest reasoning and agent tasks.
NVIDIA PAIR Turns Your Home Network Into a Local AI ClusterโDo You Still Need One Big GPU Server?
NVIDIA PAIR spreads local AI requests across multiple PCs, making compute more elastic while one home server can keep data and state persistent.
Why Does Immich Feel Faster on LAN Than on Remote Connections?
LAN requests usually take a shorter, lower-latency path. Remote access adds WAN capacity limits and may add DNS, TLS, proxy, VPN, or relay hops.
