Where the Archive Actually Lives
Immich’s asset lifecycle creates a question that a gallery interface can hide: where does an archive actually live? The answer is not “in the media folder” or “in the database.” Immich keeps important parts of an asset in both places, and it also supports a mode in which the original remains outside Immich altogether. This chapter compares those arrangements so the reader can decide what must be backed up together, what a storage template really changes, and why external-library files have different metadata and deletion rules.
The central distinction is between content and the relationships that make content usable. A photo can survive as a file while losing its album, owner, path, or search context. A database can preserve those relationships while containing none of the photo’s pixels. A safe operating model has to keep both sides aligned.
The archive has two authoritative stores
Postgres is the durable record of Immich’s application state. The documentation identifies paths and user metadata among the information stored there, along with the relationships needed for users, assets, albums, authorization, and sharing. Immich does not treat the library folder as a complete database that it can simply scan to reconstruct all of those relationships. That is why a filesystem copy alone is not a database backup.
The filesystem is authoritative for a different part of the system: original photos and videos, plus generated material such as thumbnails, encoded video, and profile images. Immich also stores its automatic database dumps as files. Those generated files make the application faster and more capable, but the original media remains the most important content to preserve. If an operator restores only the originals, the documentation says that thumbnail and transcoding jobs must be run again. If the operator restores only a database dump, the records will point toward content that is absent.
The two stores are related by paths and identifiers. The database’s account of an asset must continue to refer to the file that is supposed to represent it. Directly changing or removing managed content can therefore create a mismatch even when the file operation itself succeeds. The application may still hold a record for a missing file, or a new file may appear without the metadata and relationships that belonged to the old one.
The diagram separates an asset record from the original and from its derivatives because each has a different role. It also shows why “backup” is not one object. A database backup can contain the record and metadata while a file backup contains the original content. External files can be represented as assets without becoming files managed by the same lifecycle.
Immich’s built-in database backups are useful for disaster recovery, but the documentation states their limit plainly: they contain metadata, not photos and videos. They must be used together with a copy of the media. The application recommends backing up the complete upload location when possible, while identifying the original-content areas as critical if an operator chooses to back up selectively. Backing up only critical originals can save space, but it shifts the cost to a later rebuild of previews and transcoded videos.
This is also a consistency problem, not only a completeness problem. If the database is copied at one moment and the files at another, the two copies can describe different worlds. The recommended approach is to stop the server while taking the backup so neither side changes during the operation.