What Must Be Restored Together for a Self-Hosted Photo Library to Remain Searchable?
Restore the originals, catalog database, and path-defining configuration as one recovery unit.
For an Immich-, Lightroom-, PhotoPrism-, or similar home NAS library, image files alone may reopen but lose people, albums, ratings, edits, locations, and search results. A searchable recovery must align the media files with the database or catalog that describes them, the configuration that maps their paths, and any secrets or application version needed to read that state.
Define Searchability as More Than Opening Original Files
A photo library is searchable when the application can connect each original to its database record, metadata, album membership, people assignments, and path. Being able to open a JPEG proves file recovery, not library recovery.
An Immich recovery discussion shows that the database contains file locations and library metadata while the actual photos remain in the upload folders. Restoring only one side can produce thumbnails or records that point to absent originals.
Write the required outcome before restoring: originals open, timeline dates are correct, albums appear, people search works, edits or ratings return, and users retain access. That outcome defines which components belong to the recovery unit.
Restore Originals and the Catalog From the Same Time Boundary
The media tree and its catalog should represent the same recovery point. A newer database can reference files missing from an older media copy, while an older catalog can ignore photos that exist on disk.
A Lightroom recovery case required a two-step restore: first the photo folder, then a matching catalog backup from before the incident. The same dependency applies to self-hosted libraries that store edits, ratings, people, or albums outside the originals.
Select the closest common timestamp across the media backup, database dump, and configuration copy. If no common point exists, restore to an isolated instance and reconcile the gap before exposing the library to users.
Preserve Paths, Identifiers, and Configuration That Join the Pieces
A catalog can be healthy and still show missing assets when the restored path, mount name, volume identifier, or library root differs from the stored reference. Path consistency is therefore part of the recovery, not a post-restore cosmetic task.
Lightroom users report that restored files must retain the same names and folder structure. For container apps, the equivalent may be a bind-mount path, environment variable, database URL, or storage root.
Restore the Compose file or app configuration, environment variables, secrets, user IDs, and mount definitions beside the database. Do not bulk-relink or rescan until you have confirmed which identifiers the application expects.
Separate Required State From Regenerable Search Assets
Originals, database records, user data, album relationships, edits, and configuration are normally required. Thumbnails, cached models, and some machine-learning embeddings may be regenerable, but the library can remain slow or partially unsearchable until those jobs finish.
A current Immich deployment guide describes separate services for the server, machine learning, and background job queue, and notes built-in database backup scheduling. Those components explain why search and people recognition can depend on more than the visible media directory.
Document which generated assets can be rebuilt and how long regeneration takes. If rebuilding would consume days of CPU time or the original model state cannot be reproduced, protect that asset as part of the practical recovery unit even if the application can technically recreate it.
Match the Restored State to a Compatible Application Version
A catalog or database may require the application version that created or migrated it. Starting an older service against newer state, or vice versa, can fail before the media is evaluated.
Photo-library users have encountered catalog-version incompatibility. Preserve the deployed image tag, migration notes, and database version so the test environment can reproduce the expected upgrade path.
Start the restored library offline or under a temporary name. Confirm database migrations, user login, and path resolution before allowing mobile clients or background jobs to modify the restored state.
Validate Search, Albums, and People Before Cutover
Use an isolated restore test that includes representative old and new photos, edited items, multiple users, shared albums, location metadata, and known people. Search for records whose expected result is already documented.
The existing ZimaSpace Immich family photo backup plan provides the adjacent planning context; this restore test must now prove that those components return together.
Cut over only when originals open, counts match, albums and permissions return, search results are plausible, and a new upload indexes correctly. Keep the previous instance and recovery files unchanged until the test library has survived a restart and a fresh backup.
Recommended products
Support & Tips
More to Read
Why Does a Docker Volume Restore Recreate File Contents but Drop Extended Attributes?
A volume-restore diagnosis covering xattr inventory, tar and Rsync options, namespaces, destination support, privileges, labels, app metadata, and tests.
Why Does a Running Container Keep Its Old Memory Limit After the Compose File Changes?
A memory-limit diagnosis covering live cgroups, restart versus recreation, Compose fields, hard and soft limits, parent scopes, swap, and runtime heaps.
Why Does Restarting a Reverse Proxy Invalidate Every Session for One Self-Hosted App?
A session-loss diagnosis covering restart scope, cookie ownership, secret rotation, cache-backed sessions, sticky routing, auth gateways, and recovery.
