Immich moves fast, and its release notes don't sugarcoat it: major versions run database migrations that are not reversible. That's why upgrade day makes people nervous — and why the usual reassurance ("I have a backup of my photos") is the wrong reassurance. Your originals are rarely the thing at risk. The thing at risk is the database that knows about your albums, faces, and metadata, and the only thing that makes an Immich upgrade calm is a database restore you've actually performed.
Why a file backup isn't enough
Immich is a database-plus-files app (the same shape as the Immich/Nextcloud migration rules). Copy the upload folder and you've saved the pixels, not the meaning — albums, people, search, and timeline all live in Postgres. An upgrade that migrates the schema forward and then fails leaves you needing to restore that database to its pre-upgrade state. A folder copy can't do it.
The backup that actually protects an upgrade
Before any major upgrade:
- Stop Immich so the database is quiescent.
- Dump the Postgres database with
pg_dump(Immich documents the exact command for its bundled Postgres — use it; a plain copy of the data dir is not a clean dump). - Note the current version. You can only restore into the same version you dumped from — never an older binary against a newer schema.
- Keep the dump off the box, alongside the library.
Rehearse the restore once — before you need it
The dump is half the insurance; restoring it is the other half. Do it once on a scratch target:
- Stand up the same Immich version, restore the dump, point it at a copy of the library, and confirm albums and faces come back.
- That single rehearsal converts "I think this works" into "I've watched it work" — the whole point of a restore drill.
Upgrade sequence that removes the fear
- Read the release notes for breaking changes and required steps.
- Stop Immich; dump the database; record the version; copy off-box.
- Upgrade to the new version (only ever forward).
- Let migrations run; verify the timeline, albums, and a face search.
- If it's wrong: restore the dump into the old version, and retry the upgrade after addressing the noted issue.
Make backups routine, not heroic
The reason people skip the dump is that it's manual. Put it on a schedule (a nightly pg_dump shipped off-box) so every day is a near-upgrade-ready state, and an actual upgrade just adds one fresh dump on top. A managed deploy that includes scheduled database backups removes the main excuse — the boring discipline behind an easy, durable Immich install.
Checklist
- Database dumped with the documented
pg_dump, not a file copy. - Current version recorded; restore only into the same version.
- Dump stored off-box with the library.
- A restore rehearsed once on a scratch target.
- Routine scheduled DB backups so upgrades start from a known-good state.
Takeaway
Immich upgrade anxiety is rational and misdirected. The risk isn't your photos; it's the database that gives them meaning, and Immich's migrations don't roll back. Dump the database before you upgrade, only restore into the matching version, and rehearse it once. Do that and "new major version" stops being a held breath.