.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
Of everything on your servers, the photo library is the dataset with no second chance: configs can be rebuilt, media can be re-ripped, but the kids' photos exist exactly once. So Immich backup deserves doing properly, and the good news is the project meets you halfway with automatic database dumps built in. The other half, the actual photo files and getting copies off the machine, is on you. Here's the complete arrangement, sized for a normal self-hoster's patience.
Database and files: The two halves of an Immich backup
Immich's state splits cleanly. The database holds everything you've done in the app: users, albums, face names, favorites, edited metadata, the map of which file belongs to whom. The files under UPLOAD_LOCATION hold the photos themselves. Lose the database and keep the files: painful re-import, albums and faces gone. Lose the files and keep the database: catastrophe, the database is a beautiful index of nothing. A real backup covers both, and they travel together, ideally from the same moment in time.
Half one: The built-in database dumps
Every Immich server ships with automatic database backups already running: a dump lands in UPLOAD_LOCATION/backups daily at 2:00 AM, with the last 14 kept, per the official backup docs. Administration » Settings » Backup adjusts the schedule and retention. Check yours exists right now (ls that folder); a fresh .sql.gz with today's date is the system working.
Restoring got civilized in recent versions too: Administration » Maintenance lists the dumps with a Restore button, and a fresh install's onboarding offers restore-from-backup directly. The command-line route (stop containers, feed the dump to Postgres, restart) remains for disaster scenarios, but for the common "undo the last bad day" the button does it.
One dump-related habit worth adopting: take a manual dump before major version updates, on top of the nightly ones, since majors are when database migrations happen and the pre-migration state is the one you can't recreate afterwards. That routine and why downgrades need it are covered in the Immich update guide.
Half two: Back up the files (and what to skip)
Inside UPLOAD_LOCATION, not everything deserves backing up. The must-haves are upload/ (the originals your phones sent), library/ (originals when the storage template is on) and profile/ (avatars, tiny). The skippables are thumbs/ and encoded-video/, both derived data Immich regenerates on demand; leaving them out cuts backup size by a third or more at the cost of a regeneration job after a restore. The backups/ folder with the database dumps rides along, which conveniently keeps both halves in one copy operation.
The tool barely matters; the offsite part does. A nightly rsync to any second machine covers the honest minimum:
rsync -a --delete --exclude 'thumbs' --exclude 'encoded-video' \
/opt/immich/library/ backup-host:/backups/immich/A step up in seriousness is a real backup tool with versioning and encryption (restic and borg are the community favorites, and Immich's docs point the same direction), which protects you from the failure rsync can't: a deletion or corruption mirrored faithfully to the backup before you notice it. Versioned snapshots mean last Tuesday still exists. Cron either approach nightly, an hour after Immich's own 2 AM dump so the fresh database rides along.
Where to send it: any second location beats none, and the options stack. Another machine at home, a cheap object bucket, or a second VPS; a storage VPS makes a tidy restic target with room for years of snapshots. Layer zero, worth stating for VPS folks: the provider-side snapshot (the auto-backup slot on our plans) protects against whole-machine loss in one click, and pairs with rather than replaces the file-level backup, because "restore the whole server to Thursday" and "recover one album" are different tools.
Test the restore procedure
An untested backup is a mood, not a plan, so run the drill one time: spin up a scratch VPS or VM, install Immich the normal way, copy your backed-up UPLOAD_LOCATION into place, choose restore-from-backup during onboarding (or the Maintenance restore afterwards) and confirm your albums, faces and a random photo from 2019 all survived. Then tear it down. The exercise takes an evening, converts your backup from theory to fact and doubles as the documented procedure for the day you migrate servers on purpose.
Steady state, this whole system is two cron lines and a monthly glance: dumps happening (a current file in backups/), sync happening (recent timestamps on the far side) and disk not creeping toward full. That's the entire price of the one dataset in the house that genuinely can't be bought back, wich seems like a fair trade to me.
