Home / Software / Immich / How to Back Up Immich: Protecting Your Photo Library

How to Back Up Immich: Protecting Your Photo Library

How to Back Up Immich: Protecting Your Photo Library

Table of Contents

Immich has become the go-to self-hosted alternative to Google Photos, but there is one thing it does not do for you: back itself up. Unlike cloud services where your photos are someone else’s problem, running Immich means the responsibility for protecting your library falls entirely on you. A failed drive, a botched upgrade, or a corrupted database could wipe years of memories in seconds. This guide walks through exactly what needs backing up, how to do it properly, and how to build a reliable routine that will save you when things go wrong.

What You Actually Need to Back Up

Immich stores your data in two completely separate places, and you need both. Miss either one and your restore will be incomplete at best, catastrophic at worst.

1. Your Upload Location (UPLOAD_LOCATION)

This is the directory where all your photos and videos live on disk. It is defined in your .env file — typically something like /opt/immich/library. This is the raw media: every JPEG, RAW file, and video you have ever uploaded. If you only back up one thing, make it this.

2. The PostgreSQL Database

This is the part most people overlook, and it is the part that hurts most when lost. The database contains all of Immich’s intelligence: your album structure, face recognition assignments and name tags, shared links, user accounts, starred photos, and all the metadata that makes your library organised rather than just a folder of files.

If your drive fails and you only have the media files, you will get your photos back — but you will lose every album you have ever created, every face you have ever named, every star you have applied, and every shared link you have sent. The photos survive; everything you did with them does not. Always back up the database.

Back Up Before You Do Anything Else

Before running a backup, stop the immich-server container. This prevents the database and your media files from getting out of sync mid-backup, which can cause subtle corruption that only surfaces when you try to restore.

docker compose stop immich-server

You do not need to stop the database container itself — the PostgreSQL dump command works while Postgres is running. Just pause the application layer.

Backing Up the Database

Use a SQL dump rather than copying the database files directly. A filesystem copy of a live Postgres data directory is unreliable; a dump is clean, portable, and straightforward to restore.

docker compose exec -T immich-postgres pg_dumpall -U postgres > /backup/immich-db-$(date +%Y%m%d).sql

This creates a dated SQL file in /backup/ — adjust that path to wherever you want to store your backups. The $(date +%Y%m%d) part automatically names the file with today’s date, so you build up a rolling set of daily dumps.

To restore the database from a dump:

docker compose exec -T immich-postgres psql -U postgres < /backup/immich-db-YYYYMMDD.sql

Replace YYYYMMDD with the date of the dump you want to restore from. Make sure the Immich stack is stopped before restoring, then bring everything back up once the import completes.

A Note on Automated Database Backups

The standard Docker Compose installation of Immich does not include automated database backups — this is something you have to script yourself. Immich Distribution (a community fork of Immich) does offer built-in automated backup functionality, but if you are running the official release, you are on your own here. The good news is that a simple cron job handles this perfectly well.

Backing Up Your Media Files

Once the immich-server container is stopped, back up your UPLOAD_LOCATION directory using rsync or a straightforward file copy to another drive or NAS:

rsync -av --progress /opt/immich/library/ /mnt/backup/immich-library/

Rsync is ideal here because it only transfers changed files on subsequent runs, making daily backups fast once the initial copy is done. Point it at an external drive, a NAS share, or a remote server — anywhere that is not the same physical disk as your Immich data.

For more serious setups, Borg Backup is widely used in the Immich community. It offers deduplication (so identical files across multiple backups are stored only once), compression, and encryption at rest. The official Immich documentation includes a template backup script using Borg that handles both the database dump and the media directory in one go.

Borg is particularly useful if you are backing up large libraries where storage efficiency matters, or if you are sending backups offsite and want encryption without managing keys yourself.

The 3-2-1 Rule

Follow the 3-2-1 backup rule: three copies of your data, on two different types of media, with one stored offsite. In practice for an Immich setup this might look like:

  • Copy 1: The live Immich library on your local server
  • Copy 2: A backup on an external HDD or NAS on your local network
  • Copy 3: An offsite or cloud backup

For UK users, Backblaze B2 is the most cost-effective offsite option at roughly $6 per terabyte per month. It integrates well with rclone, which can sync your backup directory to a B2 bucket automatically. Alternatively, a second physical site — a family member's house with a small NAS — works just as well and costs nothing ongoing.

How Often Should You Back Up?

For an active library where you are regularly uploading photos, daily backups are the sensible default. The database in particular changes every time Immich processes a new photo, assigns a face, or you make any organisational change — daily captures all of that. For the media files, daily is also recommended if storage allows, though weekly may be acceptable if your upload rate is low.

Automate everything with cron. A simple crontab entry can stop the server container, run the database dump, trigger the rsync, and restart the container — all at 2am when nobody is using it.

Test Your Restores

A backup you have never tested is a backup you cannot trust. Periodically do a dry run: spin up a second Immich instance on a spare machine or VM, restore your most recent database dump and a subset of your media files, and verify that albums, faces, and photos are all present. It is far better to discover a problem with your restore procedure during a test than during an actual emergency.

Always Back Up Before Upgrading

Immich updates frequently, and database schema changes can make downgrades impossible. Before every upgrade, run a full backup — database dump and media files — so you have a known good state to return to if something goes wrong. The upgrade command itself is straightforward:

docker compose pull && docker compose up -d

But do not run it without a fresh backup in hand. Immich's changelog occasionally includes notes about breaking changes; a backup means a failed upgrade is an inconvenience rather than a disaster.

If Immich Goes Down

If your Immich instance becomes inaccessible, start by checking the container logs:

docker compose logs immich-server --tail=100

Most issues are either a failed upgrade, a full disk, or a database connection problem. If the database is the culprit, restore from your most recent SQL dump. If media files are missing or corrupted, restore from your media backup. Having both backed up separately means you can address each problem independently rather than starting from scratch.

The small amount of time it takes to set up a proper backup routine is nothing compared to the time it would take to re-organise a library from scratch — or the fact that some of that organisation simply cannot be recreated from memory. Get it done once, automate it, and test it periodically.

Author

Related Posts

Immich: The Complete Self-Hosted Google Photos Alternative
Immich vs PhotoPrism vs Piwigo: Best Self-Hosted Photo App?
Immich vs PhotoPrism vs Piwigo: Best Self-Hosted Photo App?
Immich Face Recognition and Smart Search: How to Enable It
Immich Face Recognition and Smart Search: How to Enable It