Immich as the De-Google Gateway: Great App, Serious Backup Responsibility

Immich is one of the most compelling self-hosted apps because it addresses problems most households actually feel: phone photos, family sharing, search, and cloud dependency. It also changes who is responsible for preserving those photos.

Immich documentation is clear that deployment, storage, and backup responsibilities sit with the operator. Once family photos live primarily on your server, the backup plan is not a side project; it is part of the product.

Design principle: Immich is a photo service, not a backup strategy. Back up the database, originals, thumbnails, and configuration, then prove that restores work.

The Decision

Component	Backup Need	Why
Postgres database	Consistent database dump or supported backup path.	Stores metadata, albums, users, and state.
Upload library	File-level backup of originals and generated assets.	Contains the actual photos and videos.
Compose, environment, and config	Versioned backup.	Needed to recreate the service.
Offsite copy	Encrypted remote or rotated drive.	Protects against loss at home.
Restore test	Run quarterly or after major changes.	Proves the plan works.

Deployment Shape

Run Immich on a Linux virtual machine (VM) or host with local solid-state drive (SSD) storage for the database and reliable storage for media. Keep remote access private through a virtual private network (VPN) or hardened Hypertext Transfer Protocol Secure (HTTPS) access. Do not make the app public until you understand authentication, updates, backups, and proxy headers.

Migration Plan

1. Install Immich in a test stack.
2. Upload a small sample set from one phone.
3. Back up the database and media paths.
4. Restore to a spare VM or an alternate path.
5. Verify sign-in, albums, thumbnails, and full-resolution downloads.
6. Only then import larger phone libraries or Google Takeout exports.

Family Operations

• Explain that sync is not backup.
• Keep original cloud copies or device copies during migration.
• Use albums and sharing intentionally.
• Monitor storage growth.
• Document account recovery and admin credentials.

Understand the Current Data Model

An Immich recovery needs two coordinated classes of data: the PostgreSQL database and the asset files under the configured upload location. The database holds file paths and application metadata; it does not rebuild itself by scanning the library directory. Immich's current documentation also warns that automatic database dumps do not contain photos or videos. A green database-backup entry therefore does not mean the photo library is protected.

The filesystem contains originals plus generated content such as thumbnails and encoded video. Current documentation identifies original uploads under the configured upload or library paths depending on storage-template use, with profile data in its own path. Backing up the complete UPLOAD_LOCATION is the straightforward policy. An advanced operator may omit regenerable thumbnails and encoded video to reduce backup size, but that trades storage cost for a longer, more resource-intensive rebuild and requires confidence that every original and database record is present.

Do not edit, rename, or reorganize managed files behind Immich. Use the application for normal changes and treat the storage tree as application state. External libraries have their own mount paths and must be included deliberately. A backup job that follows only the default Compose directory can miss media mounted from a NAS.

Version and Capacity Caveats

As checked on July 15, 2026, Immich's requirements page lists a 64-bit Linux or Unix-like system as the recommended host, 6 GB of RAM minimum and 8 GB recommended, two CPU cores minimum and four recommended, and the Docker Compose plugin invoked as docker compose. It recommends local SSD storage for PostgreSQL rather than a network share. Those are project requirements, not TechGeeks measurements or a promise that a given library, machine-learning workload, or concurrent family workload will perform well.

The current backup documentation says the backup and restore process changed in Immich v2.5.0 and directs operators with older backups to the matching documentation version. Record the Immich version with every database dump and before every upgrade. Preserve the Compose file, environment-variable names, mount map, and storage-template state, but keep secrets in a protected credential record rather than an exposed repository.

Capacity planning must include growth and recovery headroom. Photos grow steadily; videos grow in bursts; thumbnails and transcodes add generated data; database dumps and filesystem snapshots consume more space. Immich currently estimates that thumbnails and transcoded video can add roughly 10 to 20 percent on average, but a library's formats and settings can differ. Measure your own path sizes and growth instead of sizing a purchase from that estimate alone.

Build a Backup Topology

A practical home design has the live Immich stack, a versioned local recovery copy, and an encrypted offsite or offline copy controlled through separate credentials. A NAS snapshot is useful for quick rollback, but it is not offsite when the NAS and server share the same room, power, administrator, and theft or fire boundary. A cloud copy is offsite, but it is still vulnerable to account loss, retention mistakes, cost changes, and deletion if the same credentials control everything.

Consistency matters. Immich recommends stopping the server while capturing both database and files when that maintenance window is acceptable. If live backup is required, its documentation recommends database first and filesystem second so the worst case is an unreferenced file rather than a database record that points to an absent file. That ordering reduces one inconsistency mode; it does not prove an application-consistent backup under every workload.

• Daily: create and copy a supported database dump, then capture changed assets with a backup tool that retains history.
• Weekly: verify the newest offsite object or rotated drive, free space, job exit status, and backup age.
• Quarterly: restore the database and a representative asset set to an isolated test stack using the matching Immich version.
• Before upgrades: record the current image versions, create a fresh database dump, confirm the asset backup, and keep the previous Compose definition and images available for rollback.
• Annually: run a recovery assuming the original server and password manager are unavailable; verify offline recovery credentials and family handoff notes.

Restore and Rollback Method

1. Create an isolated network or test host. Do not point a recovery rehearsal at the production database or production upload path.
2. Install the documented Compose definition for the backup's version and recreate the same mount paths. Confirm ownership and permissions before starting the application.
3. Restore the asset files and select the matching database backup using the current supported workflow. Immich's restore interface reports version compatibility and performs integrity checks; read those results rather than clicking through them.
4. Sign in with a recovery account. Open recent and old assets from more than one user, inspect albums, search, faces if enabled, metadata, thumbnails, and full-resolution downloads. Test a video rather than checking photos only.
5. Compare record counts and representative file hashes or sizes against the backup manifest. Record missing assets and permission errors.
6. Delete the isolated stack after retaining the test record. A test environment contains private family data and should not become an unmanaged extra copy.

For an upgrade rollback, stop writes, preserve the failed stack and logs, and follow the version-specific restoration guidance. Do not assume that restarting an older container against a database already migrated by a newer release is safe. Recover the matching pre-upgrade database and files together. Immich's current interface creates a database restore point for its supported restore workflow, but that application rollback does not replace a separate filesystem backup.

Security, Privacy, and Legal Boundaries

A photo server holds faces, homes, children, locations, schedules, documents, and device metadata. Use unique administrator credentials, multi-factor authentication or a well-controlled identity provider where the deployment supports it, HTTPS, prompt supported updates, restricted database access, and encrypted backups. Prefer private remote access through a VPN or another identity-aware access layer. If publishing through a reverse proxy, document trusted proxies, upload limits, certificate renewal, logs, and the emergency path when the proxy or identity provider fails.

Decide who may create accounts, share albums, download originals, or use facial recognition and location search. Laws and household expectations around children's data, biometric templates, copyright, consent, and retention vary by jurisdiction and context. This guide is not legal advice. The operator should explain the storage and sharing model to family members and obtain specialist advice for school, client, employee, healthcare, or other regulated collections.

Evidence and Restore Acceptance Tests

This revision is documentation-backed. TechGeeks did not install Immich, import a Google Takeout archive, measure indexing speed, inspect image quality, or perform a restore. The diagram is an explanatory data-flow model. It is not a screenshot or artifact from a working deployment.

• Retain a timestamped inventory of Immich version, Compose file hash, environment-variable names, volume mappings, database-backup file, filesystem-backup snapshot, and offsite copy.
• Set acceptance criteria before migration: all selected users can sign in; representative recent and old photos open at full resolution; videos play; albums and metadata appear; expected asset counts reconcile; and no integrity or permission errors remain.
• Verify the backup through a clean isolated restore, not by opening files directly inside the production storage tree.
• Keep Google Photos or original device copies until at least one independent restore passes and the household accepts the new recovery process.
• Test loss of the primary server, not merely deletion of one photo, so the rehearsal includes credentials, DNS, TLS, storage mounts, database restoration, and application startup.

A successful mobile upload does not prove the server copy is backed up. A database dump does not prove originals are present. A filesystem copy does not prove albums, users, or metadata can be reconstructed. One successful restore does not prove future backups, upgrades, retention, offsite credentials, or every asset are correct. Keep recurring, claim-specific evidence rather than treating a green dashboard as complete recovery proof.

Useful Gear and Buyer Notes

Affiliate disclosure: As an Amazon Associate, TechGeeks may earn from qualifying purchases. The product links below are buying references, not a requirement to buy a specific brand or seller. Verify compatibility, seller quality, warranty, and current specs before ordering.

Need	Good Choice	Why It Fits	Affiliate Link
Photo storage	Network Attached Storage (NAS) drives	Photos deserve reliable storage and monitoring.	Amazon: WD Red Plus 8TB Amazon: Seagate IronWolf 8TB
Database disk	Non-Volatile Memory Express (NVMe) SSD	Postgres and thumbnails benefit from fast local storage.	Amazon: NVMe SSDs
Offsite copy	External drive or cloud backup target	Protects family photos from local loss.	Amazon: Samsung T7 Shield 2TB Amazon: external backup drive
Power	Uninterruptible Power Supply (UPS) for server or NAS	Helps prevent corrupted writes during uploads or maintenance.	Amazon: CyberPower CP1500PFCLCD Amazon: APC BR1500MS2
Server	Mini personal computer (PC) or NAS app platform	Runs Immich without needing a full-size server.	Amazon: Intel N100/N305 mini PCs

Common Mistakes

• Assuming phone sync equals backup.
• Backing up only the database.
• Deleting Google Photos copies before a restore test.
• Ignoring storage growth from videos.
• Exposing Immich publicly before hardening the stack.

Related TechGeeks Resources

• The 3-2-1 Backup Rule in 2026: Keep It, But Add Two Checks
• The Safest Way to Expose One Self-Hosted App
• UPS Buying Guide for Home Servers: Runtime Is Not the Main Point

References

• Immich Quick Start
• Immich Requirements
• Immich Backup and Restore
• Immich Storage Template
• CISA StopRansomware Guide
• Backblaze 3-2-1 Backup Strategy

Final Thought

Immich is powerful because photos matter. That is also why it deserves a serious backup plan before it becomes the family source of truth.

This Immich migration guide belongs to the TechGeeks homelab roadmap. It addresses recurring photo-ownership and self-hosting questions, then checks the operating advice against current Immich backup and restore documentation, ransomware guidance, and independent backup practice.