Should You Back Up Immich Live or Stop the Service First?
Stop Immich first when you want the simplest, easiest-to-explain consistency boundary; use a live backup only when you can take a database-native dump and coordinate the media capture or snapshot so their restore relationship is known.
Immich stores asset records in PostgreSQL while originals and derived files live on storage, so an ordinary live recursive copy can observe different moments. For a small household, a short maintenance window is often safer than complex orchestration. When continuous uploads matter, keep the service live but use database-aware tools, record the capture order, protect newly arriving assets, and judge the backup by an isolated restore.
Define Every Component the Restore Must Recreate
Inventory the PostgreSQL database, upload library, generated media needed by your policy, external-library definitions, Compose and environment files, secrets, proxy settings, and encryption keys. Classify which items Immich owns and which can be regenerated.
A hands-on database backup article explains using a PostgreSQL dump rather than treating the live database directory like ordinary files. Its database-aware backup method supports the live path; confirm commands and versions for your deployment.
A plan fails if it protects originals but cannot restore their records, or protects the database while omitting media. Write the restore order beside the backup order before choosing whether downtime is acceptable.
Choose a Stopped Backup for the Clearest Boundary
Pause uploads, stop the Immich application and workers cleanly, then take a database-native backup and copy or snapshot the media plus deployment files. Keep PostgreSQL running only as required for the dump, or stop it cleanly before a storage-level snapshot designed for that service.
Stopped service does not fix wrong paths or incomplete scope, so verify mounts and archive sizes. A pass has no active Immich writes during capture, a successful database backup, readable media samples, checksums, and a documented restart time.
The ZimaSpace guide to verifying backup keys and restores reinforces that a quiet copy is not recoverable until its credentials and restore path are tested.
Use a Coordinated Live Backup When Uptime Requires It
For a live plan, create a database-native consistent dump and pair it with a storage snapshot or file capture whose timing and write behavior are understood. Record start and completion times, keep newly arriving uploads until the next backup, and avoid copying the raw live database directory.
A community discussion about backing up Immich from a running deployment shows why operators distinguish the database from upload files. Use that live-backup boundary as practical context, not a substitute for a restore test.
A live design passes only if the database tool completes cleanly, the filesystem capture is atomic or its ordering is documented, and uploads created during the window are accounted for. Otherwise choose the stopped route or increase backup frequency to reduce the maintenance window.
Restore in Isolation and Make the Final Choice
Restore the selected database and media to an isolated target with the saved deployment files. Check users, asset counts, sampled originals, albums, favorites, searches, external libraries, and a new upload. Restart the target and repeat critical checks.
Choose stopped backups when their downtime fits the household and simplicity reduces error. Choose coordinated live backups when availability justifies added tooling and repeated restore tests prove the process. The decision can change as library size and upload frequency grow.
Stop production retirement if the restore has missing-file or orphan-record errors. Preserve both backup components and logs, then reconcile timestamps and scope. Escalate with database version, dump method, filesystem method, capture times, and mismatch counts; never prune the last stopped backup until the live method has passed independently.
Recommended products
Support & Tips
More to Read
How to Optimize Immich Database Connections for Concurrent Containers
Do not raise max_connections first. Measure Immich sessions, total every container's demand, preserve admin headroom, and tune only the proven bottleneck.
How to Prevent Duplicate Jobs or Imports in Immich
Separate repeated jobs from duplicate assets. Use one canonical ingestion path, control retries and path changes, then test re-entry on a small cohort.
How to Repair Immich After Its Database Volume Fills Up
Never delete PostgreSQL WAL to free space. Stop Immich writes, preserve database state, add safe capacity, recover PostgreSQL, then prevent recurrence.
