Most Immich backup advice stops at "copy your upload folder". That instruction protects the irreplaceable part - your original photos - and loses almost everything else.
An Immich instance is two things that must be saved together: the media files on disk, and the PostgreSQL database that knows what those files mean.
What lives where
The upload location holds the originals, plus generated thumbnails and encoded videos. This is the part you cannot recreate: if it is gone, the photograph is gone.
PostgreSQL holds everything that turns those files into a library - albums, the people and faces recognised by machine learning, shared links, users and permissions, and above all the mapping between each database row and its file on disk.
Save only the files and you keep your photos as an undifferentiated pile: no albums, no faces, no shared links, and re-importing means re-running every bit of machine learning. Save only the database and you have a meticulous index pointing at files that no longer exist.
Backing up the database properly
Take a PostgreSQL dump. Do not copy the database's data directory while the container is running: a live copy is usually an archive that cannot be replayed, and it fails silently until the day you need it.
The dump runs against the database container while everything is up, so it needs no downtime. Run it on a schedule, and keep several dated copies rather than overwriting one file - a corruption you do not notice is a corruption you will faithfully propagate over your only good copy.
Consult the official Immich documentation for the exact command for your version: it has changed with the database images, and a command copied from an old forum thread is how people end up with dumps that do not restore.
Backing up the media
The upload location is a large, mostly-append-only directory. Any reliable file copy works - rsync to another machine, a NAS replication job, an object-storage sync - as long as it is not on the same disk as the original. A copy on the same drive protects you against deletion, not against the drive.
Two details worth getting right:
- Keep the media backup and the database dump roughly in step. A dump from Monday and media from Friday will reference photos the dump does not know about. Immich tolerates this better than the reverse, but the closer they are, the cleaner the restore.
- Watch the external libraries. If you added photos through an external library rather than by upload, those files live outside the upload location and your backup script probably does not touch them.
Snapshots are not an answer on their own
A ZFS or VM snapshot taken while PostgreSQL is writing captures the database mid-transaction. Sometimes it replays. Sometimes it does not - and you discover which the day you restore.
Snapshots are genuinely useful for the media and for fast rollback. They are not a substitute for a dump. Take both: the dump costs seconds and it is the piece that decides whether the restore works at all.
Prove it restores - once
This is the step almost everyone skips, and it is the only one that turns an archive into a backup.
- Bring up a second Immich instance - another machine, or the same one on different ports and volumes.
- Restore the database dump into it.
- Point it at a copy of the media (never the original, so a mistake cannot destroy what you are protecting).
- Open the interface. Are your albums there? The recognised people? A shared link you remember?
If yes, you have a backup. If the interface loads but the library is empty, your dump and your media were out of step - better to learn it now than in a year.
The short version
Back up both halves: a scheduled PostgreSQL dump and a copy of the upload location, on separate hardware, kept roughly in step, with several dated copies. Do not rely on snapshots alone for the database, and restore once into a test instance to prove the whole thing works. Immich is exactly the kind of service where an untested backup stays silently broken for months - and it is holding the photographs you cannot take again.
Frequently asked questions
- What do I need to back up in Immich?
- Two things, and both are required. First the media files - the upload location holding your original photos and videos. Second the PostgreSQL database, which stores albums, people and faces, shared links, users, and the mapping between database entries and files on disk. Save only the files and your photos survive as a pile of images: albums, recognised faces and shared links are gone. Save only the database and it will point at files that no longer exist.
- Is copying the upload folder enough?
- No, and this is the most common Immich backup mistake. The upload folder contains the originals, which is the irreplaceable part - but everything that makes Immich useful rather than a directory of files lives in PostgreSQL. A backup without the database is a photo rescue, not a restore.
- How do I back up the Immich database?
- With a PostgreSQL dump run against the database container, not by copying its data directory while it runs. Copying live database files usually produces an archive that cannot be replayed. Immich's own documentation recommends a dump, and running it on a schedule with the containers up is safe. Keep several dated copies rather than overwriting a single one.
- Can I just snapshot the whole VM or dataset?
- A filesystem or VM snapshot taken while the database is running captures it mid-write, which may or may not replay. It often works and sometimes does not - and you find out which on the day you restore. If you rely on snapshots, take the database dump as well: it costs little and it is the piece that decides whether the restore succeeds.
- How do I know my backup actually works?
- Restore it somewhere else. Bring up a second Immich instance, load the dump, point it at a copy of the media, and open the interface. If your albums and people are there, the backup is real. Until you have done this once, you have an archive with unknown contents, not a backup - and Immich is precisely the kind of service where nobody notices for months.
Your server is one copy - add an offsite one → pCloud Crypto
Client-side encrypted, so the provider cannot read the copy it holds
