Technical Anshu
Tutorials Blog
🛟 Immich Backup

Back Up Your Immich Server the Right Way Library Plus Database

You built Immich so your photos would be safe. Now the uncomfortable question: what is protecting Immich? A server is one disk failure, one bad update or one house accident away from being the thing you needed a backup of. Here is the complete, honest routine.

✍️ Technical Anshu🐳 Docker / Linux Server⏱️ 7 minute read
🎥 The install is only half the story in the video — this guide is the other half

Every Immich owner eventually understands the sentence the project itself repeats: a self-hosted server is a copy, not a backup. The phone backs up to Immich — good. But if the Immich disk dies, both the 'original' on the server and the convenience copy are gone together, and the phone may already have been cleared. A real backup means the whole Immich — library and database together — exists somewhere else, on a schedule, without you remembering.

A complete Immich backup has two halves
Half one — the library
UPLOAD_LOCATION — originals, thumbs, database dumpsCOPY
Half two — the database
PostgreSQL dump — albums, people, dates, search dataCOPY
Where it must live
A different disk, ideally a different buildingRULE

👆 Example backup map. Files without the database lose their organisation; the database without the files is a catalogue of ghosts.

1

The Two Halves — and Why Half a Backup Restores Nothing

  1. The library (your UPLOAD_LOCATION): the original photos and videos, plus generated thumbnails and Immich's own automatic database dump folder
  2. The database: albums, people, faces, dates, locations, sharing and search data. Without it, restored photos arrive as an anonymous pile of files — present, but stripped of everything that made them a library
  3. Restore needs both halves from the same point in time. A library from June with a database from October describes photos that do not exist and forgets photos that do
2

The Database Half — Use a Real Dump

Copying the live database folder of a running server can produce a torn, inconsistent copy. The supported approach is a logical dump while Immich runs:

  1. Immich helps you already: it takes automatic database backups on a schedule and stores the dumps inside the upload location, in the backups folder. Check in the administration settings that this feature is on and note its schedule
  2. That means a faithful copy of the whole UPLOAD_LOCATION quietly includes recent database dumps — the design is deliberate
  3. For a manual dump before something risky (an update, a disk move), the standard tool is pg_dump run against the database container — do it before the risky thing, not after it goes wrong
  4. Keep several generations, not just the latest. A corruption you notice after a week needs last week's dump, not last night's copy of the same corruption
3

The Schedule and the Destination

  1. Automatic, not remembered: a scheduled job (a backup tool, a sync task, a simple cron script) copies the library nightly or weekly to a second disk — a USB drive, a NAS, another machine
  2. One copy off-site: a disk at a relative's house, or encrypted cloud storage, protects against the events that take the whole room — theft, fire, flood. The classic rule is 3 copies, 2 different media, 1 off-site
  3. Encryption if it leaves the house: photo archives are the most personal data a family owns. Whatever carries the off-site copy should be encrypted
  4. Watch the watcher: once a month, open the backup destination and confirm the newest files are actually new. A backup job that failed silently in March is discovered in December, which is too late
4

The Restore Test — the Step That Separates Backup from Hope

  1. Once, on a spare machine or a test container, actually restore: install Immich, restore the database dump, point it at the copied library, and open it
  2. Confirm the photo count, the albums, the people and the dates are all present
  3. Time it. Knowing a restore takes an evening — before you are crying over a dead disk — turns panic into a plan
  4. A backup that has never been restored is a hypothesis. Test it once a year and it becomes a fact
🔴 Say it once more, because it is the whole page: Immich on one disk is one copy. The backup is done when library and database exist somewhere else, automatically, and a restore has been proven to work.

🎥 Watch the Complete Process in the Video

Build the server with the video — then protect it with this page before the first family photo lands on it.

▶️ Watch Full Video
❓ Frequently Asked Questions

Are Immich built-in database backups enough on their own?

They cover the database half — and they live inside the same upload folder on the same disk. If that disk dies, the dumps die with the library. They are an excellent component of a backup, but the whole folder still has to be copied somewhere else.

How much space does a full Immich backup need?

Roughly the size of your library plus the small database dumps — the generated thumbnails and transcoded videos are the only optional part, since Immich can rebuild them. When space is tight, back up the originals and the backups folder first and let previews regenerate after a restore.

My library is huge. Can I back up to a USB drive I plug in once a month?

Yes — an offline drive has a real advantage: it cannot be touched by ransomware or a sync mistake while it is unplugged. Monthly is a reasonable rhythm for photos. Just make it a calendar habit, and store the drive away from the server, not on top of it.

This guide is based on the Technical Anshu video linked above • Stuck on a step? Ask in the video comments — that is where answers come fastest 🙏