How to Back Up Immich Without Losing Faces, Albums, or Photos

An Immich backup is complete only when it preserves the database, original media, and configuration needed to reconnect them. Export the database, copy every referenced photo and video, protect secrets, keep an off-host copy, and perform a restore drill before relying on the plan. Immich’s backup documentation separates the database and media responsibilities clearly.

Table of Contents

• What complete means
• Inventory database and asset paths
• Database dump
• Media copy
• Configuration and secrets
• A practical 3-2-1 plan
• Restore drill
• Upgrade checkpoint
• Common failure modes
• Final preflight and next step
• Frequently Asked Questions

What complete means

A complete Immich backup contains four recovery layers:

1. The database, including albums, asset metadata, faces, people, sharing relationships, and application state.
2. Original photos and videos at paths Immich can read after restoration.
3. Generated or related files, sidecars, and additional library data required by your layout.
4. Deployment state, including compose files, environment settings, mounts, and secrets.

A database dump alone cannot restore the original media. A media copy without its matching database may preserve files but lose albums, faces, and relationships. The tradeoff is storage and time: database-only backups are smaller, while complete copies take longer but protect the library itself.

Inventory database and asset paths

Document every path before copying anything. Record the database service or location, upload and library directories, external libraries, custom locations, generated-file directories, Docker bind mounts, named volumes, permissions, compose files, environment files, and secret-storage locations.

Storage templates and mount choices affect how Immich finds files after restoration. The official storage-layout notes explain why file arrangement matters. The custom-locations guide covers additional path and mount considerations.

Use this preflight checklist:

• Database and asset paths are documented.
• Custom libraries are included.
• Mounts resolve to the intended host directories.
• The backup destination has enough capacity.
• A separate copy and restore target exist.

Database dump

Create a logical database dump before copying media or upgrading Immich. Use the database tooling supported by your deployment, and store the export outside the live database volume.

The workflow is:

1. Confirm the database service is healthy.
2. Create the dump with the supported export command.
3. Write it to a protected backup directory.
4. Confirm the command completed successfully.
5. Record its timestamp and matching deployment state.
6. Copy it to another storage location.

Do not assume that copying a database directory while its service is running is equivalent to a consistent export. A logical dump provides a distinct recovery artifact that can be imported into a replacement database.

Check the resulting file:

test -r /path/to/immich-database.dump
ls -lh /path/to/immich-database.dump
sha256sum /path/to/immich-database.dump

Replace the path with the location from your inventory. Verify readability, nonzero size, the recorded checksum, and successful import during a restore drill. Review Immich’s backup and restore documentation before standardizing the exact command sequence.

Media copy

Copy original media separately from the database dump. Include every directory Immich uses to read photos and videos, including external libraries and custom locations. Do not copy only thumbnails and assume originals can be reconstructed.

Preserve directory structure, filenames, timestamps where relevant, and readable permissions. If media is split across custom paths, either copy each source or ensure the restored host provides the same path and mount relationship.

Compare source and destination after the copy:

du -sh /source/library /backup/library
find /source/library -type f | wc -l
find /backup/library -type f | wc -l

Counts and sizes are useful signals, not proof. Investigate differences caused by active uploads, excluded files, permissions, or a changing source. A quiet copy window makes verification more meaningful. Preserve the storage-template and custom-location design deliberately; Immich’s storage documentation and custom-location guidance provide the relevant layout details.

Configuration and secrets

Preserve the compose configuration, environment settings, mount definitions, and secret values needed for the restored services to reconnect to the database and media.

Restrict access to this material, keep it out of public repositories, and document where the authoritative copy lives. If secrets change, update the backup set and record which configuration matches each database dump.

From the deployment directory, verify the configuration:

test -r /path/to/compose.yaml
test -r /path/to/.env
docker compose config

Review the rendered result for missing variables, incorrect paths, or unintended mounts. A successful parse confirms that the deployment definition is usable, not that the application has been restored.