How to Verify an Immich Restore Before Retiring the Old Server
Do not retire the old Immich server because the new dashboard loads and photos appear. Retire it only after the restored system proves users, albums, people, search, sampled originals, new uploads, background jobs, restarts, and a fresh backup while the old host remains available as a rollback target.
Keep the old server powered off but unchanged during validation so two instances do not accept uploads against diverging state. Give the restored host a controlled test address first, record a baseline from the old system, and compare the same household workflows rather than relying on a visual impression that the timeline looks complete.
Keep the Old Server Intact While You Establish a Restore Baseline
Before cutover, record user count, asset count, a few representative albums, named people, favorites, shared items, external-library paths, and several sample originals across dates and users. Also record the old Immich and PostgreSQL versions and the backup artifacts used for the restore. Folder or storage integrity checks are useful gates, but they do not replace relationship-level verification.
The ZimaSpace recovery model for restoring a searchable photo library treats originals, catalog/database state, and path-defining configuration as one recovery unit. That is the right baseline because loose image files alone cannot prove that album membership, ownership, people, and search relationships survived.
Do not wipe the old disks, reuse its IP permanently, or delete the last known-good backup yet. The verification target should be reversible: if one critical relationship is missing, you need the old state to determine whether the problem came from the backup, restore method, path mapping, or new runtime.
Verify Relationships, Not Just Photo Visibility
Log in as more than one expected user and check that each account sees the correct assets and shares. Open known albums, named people, favorites, memories or other household-specific relationships that would be difficult to reconstruct from the files alone. Compare a small set against the recorded old-server baseline.
An Immich migration discussion about missing albums after a PostgreSQL restore shows why this matters: photos could remain while album state was absent, and a later database re-dump changed the result. Treat that as case evidence that a successful login or visible timeline is not a complete restore test.
Search for several known assets using metadata and any enabled visual or people features. If originals are present but relationships or search results are missing, determine whether the relevant state should have been restored or is intentionally being regenerated. Do not retire the old server while that distinction is unresolved.
Exercise the Read, Write, Dependency, and Restart Paths
Open old photos and videos directly from the restored storage, then upload a disposable new asset from a mobile or web client. Confirm its original is written to the intended path, it appears for the correct user, and its background jobs advance. Test external libraries and remote access only after the local read/write path is stable.
Restore testing should validate the application after the bytes are copied. A current disaster-recovery testing guide recommends application-level validation that includes databases, permissions, network connections, and services rather than stopping at a completed backup or restore job. Restart the Immich stack twice and reboot the new host once. After each cycle, confirm the same mounts, users, sample assets, database, proxy or local endpoint, and job behavior return. A service that works only until the first host reboot has not passed migration.
Create a Fresh Backup Before Closing the Rollback Window
Create a new database-consistent backup and protect the media/configuration scope required by the recovery design. Restore at least a small validation target or inspect the backup with the same process used before cutover. A restored server that cannot produce its own recoverable backup should not become the only production copy.
Run the new host through a defined observation window that includes normal phone uploads, browsing, search, background processing, scheduled backup, and at least one overnight cycle. Keep the old host off so it cannot split state, but retain it unchanged until the new system survives those events without unexplained differences.
The go decision requires matching critical relationships, readable originals, successful new writes, stable restarts, and a fresh verified backup.
If users disappear, counts diverge materially, path errors return, or the database reports consistency problems, power down the new instance and preserve both sides before investigating. Only then should the old server be wiped or repurposed.
Recommended products
Support & Tips
More to Read
How to Optimize Immich Database Connections for Concurrent Containers
Do not raise max_connections first. Measure Immich sessions, total every container's demand, preserve admin headroom, and tune only the proven bottleneck.
How to Prevent Duplicate Jobs or Imports in Immich
Separate repeated jobs from duplicate assets. Use one canonical ingestion path, control retries and path changes, then test re-entry on a small cohort.
How to Repair Immich After Its Database Volume Fills Up
Never delete PostgreSQL WAL to free space. Stop Immich writes, preserve database state, add safe capacity, recover PostgreSQL, then prevent recurrence.
