Immich vs Google Photos: Which Photo Backup Setup Should You Trust?
Tech GuruGoogle Photos wins on low-friction mobile backup, sharing, and search. Immich wins when you want local control, self-hosting, and independence from a cloud-photo subscription. Both still need backup. A photo app is not the same thing as a recovery plan.
Design principle: Separate working data, local recovery, and offsite recovery. One box can help, but one box should not be the whole plan.
The Short Version
- Google Photos wins on low-friction mobile backup, sharing, and search. Immich wins when you want local control, self-hosting, and independence from a cloud-photo subscription. Both still need backup. A photo app is not the same thing as a recovery plan.
- The practical decision is operational, not cosmetic: choose the path you can document, test, maintain, and recover.
- Use the decision matrix below, then prove the result with the validation checklist before making it the default.
Why This Matters Now
Start by deciding whether the household needs a managed photo experience, local administrative control, or both. Then write down who uploads, who shares albums, who can administer recovery, and how long the family can tolerate an unavailable library. That operating model matters more than choosing the most attractive gallery.
Home labs now run real household services: DNS, photos, media, backups, smart-home control, remote access, and sometimes work-adjacent systems.
The right answer is usually not the largest option. It is the design that is documented, recoverable, and quiet enough to live with.
Prices, firmware, subscriptions, and product bundles change quickly, so verify current model numbers and vendor terms before buying.
The practical baseline is a photo experience plus a separate recovery system. The sections below sequence a small upload pilot, a metadata-aware migration, protected database and original-file backups, a disposable restore, and only then any decision to remove an older copy.
Recommended Baseline
Give the photo library three distinct locations: the working originals and application database, a local recovery copy for quick restores, and an offsite or offline copy with history. The third location must remain recoverable when the Immich host, Google account, administrator credentials, and house network are unavailable.
Automatic phone upload solves ingestion, not recovery. A mistaken deletion or damaged file can propagate through synchronized libraries, while an account problem can block every cloud-visible copy. Preserve versioned history on a target that the normal photo application cannot silently rewrite.
What Google Photos Still Wins
Google Photos is hard to beat for instant phone backup, sharing, search, and low maintenance. It is a consumer product designed for people who do not want to run a server.
The weakness is control. Export, account dependency, storage pricing, and service changes are outside your control.
What Immich Gives You
Immich gives you a modern self-hosted photo experience with local storage and more control over where the library lives.
That control comes with responsibility. The database, uploaded files, thumbnails, configuration, and server updates all become part of the operating model.
Migration From Google Photos
Use Google Takeout carefully and test with a small album before importing the whole library. Watch for metadata behavior, duplicates, edited files, and partner-shared items.
Do not delete Google Photos immediately after import. Run both systems long enough to confirm mobile uploads, search, sharing, and backup behavior.
Backup Design
For Immich, backing up the upload directory is not enough. Follow project guidance for database and configuration backup.
For Google Photos, keep an export or independent copy of irreplaceable originals. The goal is to survive account trouble, accidental deletion, and a future migration.
Decision Matrix
| Need | Google Photos | Immich |
|---|---|---|
| Lowest admin work | Best fit. | Requires server care. |
| Local control | Limited. | Best fit. |
| Family sharing | Mature and easy. | Works, but needs setup and user training. |
| Disaster recovery | Needs export and backup plan. | Needs database, library, and upload backup plan. |
Decision Worksheet
Before choosing a platform, complete this photo-specific worksheet for each household member. A person who needs effortless mobile uploads and shared albums may reach a different answer from the administrator who needs local originals, exportable metadata, predictable storage growth, and an offline recovery path.
| Worksheet Item | What To Write Down | Why It Matters |
|---|---|---|
| Primary question | Is Immich ready to replace Google Photos? | This keeps the article tied to the reader's real decision instead of drifting into a generic product comparison. |
| Affected systems | People, apps, and devices that create or need the files, photos, backups, databases, or shares. | Readers should know who and what they are protecting before they choose hardware, software, or a cloud service. |
| Failure model | Deletion, ransomware, drive failure, bad sync, account lockout, theft, fire, and hardware replacement. | Different failures need different controls. This row prevents RAID, sync, VPN, or MFA from being treated as magic. |
| Proof test | Restore a real folder, one recently changed file, and one app-owned data set to a clean location. | A recommendation is not proven until it survives a small, repeatable test using realistic data, clients, or accounts. |
| Rollback path | Keep the original copy and credentials available until restores, permissions, and metadata are confirmed. | A reversible change is less stressful, easier to explain, and less likely to turn a weekend project into an outage. |
| Measurement to capture | Usable capacity after parity, mirrors, snapshots, and retention. | Numbers, logs, screenshots, or restore notes give the reader confidence that the decision was based on evidence. |
Migration Risk Lives In Metadata
The hard part of leaving Google Photos is not only moving JPEG and HEIC files. It is preserving dates, albums, edits, shared memories, duplicates, and mobile-upload behavior. Google Takeout can produce sidecar metadata and duplicate-looking exports that need careful handling before a family trusts the new library.
Run Immich beside Google Photos first. Import a small Takeout sample, compare dates and locations, enable one phone for uploads, and confirm backup coverage for the database and upload directory. Immich should not become the only photo source until restore works on a clean host.
Real-World Example
Consider a family using three phones and a small NAS. They keep Google Photos active during an Immich pilot, upload a representative month from every phone, export a small Takeout set, and inspect timestamps, edits, albums, and duplicates. They call the pilot successful only after restoring the Immich database and matching originals into an isolated environment and opening photos there.
Classify photo data before sizing storage. Originals and irreplaceable videos come first; album assignments, edits, favorites, faces, and timestamps are application or sidecar metadata that may be painful to reconstruct; thumbnails and transcodes are usually reproducible cache. Back up each class according to its replacement cost instead of copying every generated file blindly.
A photo platform comparison is incomplete until it follows the failure. Phone loss tests whether uploads finished; pool failure tests the originals and database backup; account lockout tests independent credentials; a destructive sync tests retained history. The design succeeds only when one of those failures can be recovered without trusting the failed application or provider session.
Rollout And Recovery Plan
Roll out Immich in three passes. Inventory originals and exported metadata first. Next, enroll one phone and import one small Takeout period while Google Photos and the original folders remain untouched. Finally, back up and restore the database and files into a disposable target before expanding enrollment or deleting any cloud or local source.
Make the recovery drill representative. Restore an older JPEG with EXIF, a recent phone video, a changed or edited item, the corresponding Immich database state, and any configuration needed to start the service. Check capture time, filename, ownership, album behavior, thumbnail regeneration, and playback from a different client. Restoring onto the only healthy production host is not an isolated recovery test.
Implementation Details
Schedule bulk import, database maintenance, and storage-path changes when photo uploads and family sharing can pause. Keep the existing mobile backup path enabled during the pilot so troubleshooting an Immich import does not create a gap in newly captured photos.
- Write down the current state before changing anything: devices, accounts, IP addresses, storage paths, and who depends on the service.
- Pilot the recommendation with one device, one folder, one app, or one user before changing the entire home or lab.
- Keep the old path available until validation passes.
- Document rollback steps while the working setup is still fresh.
- Schedule a review date so firmware, subscriptions, certificates, and backups do not drift for months.
Record these details while you build, not after the memory has already gone fuzzy:
- Usable capacity after parity, mirrors, snapshots, and retention.
- Restore time for a realistic folder, VM, app database, or photo library.
- Offsite copy age and whether backup credentials are separate from normal user credentials.
- Drive health, scrub status, alert delivery, and UPS shutdown behavior.
Validation and Evidence to Collect
Useful photo evidence is concrete: an upload log from each phone, a count of source and imported originals, notes about sidecar and timestamp handling, a database backup timestamp, and a restore record showing which photos and metadata opened in an isolated instance.
- A data inventory that separates irreplaceable, painful-to-recreate, and disposable data.
- Screenshots or logs from the latest backup job, snapshot job, scrub, SMART check, and offsite sync.
- A restore note showing what was restored, where it was restored, how long it took, and what did not come back cleanly.
- A credential note proving backup administration is separate from normal daily user access.
- Capacity math that includes snapshots, retention, app databases, photo growth, and replacement-drive budget.
Failure Signals
- Backups complete but nobody has restored from them.
- Snapshots and sync jobs live on the same system as the only important copy.
- Drive, UPS, or scrub alerts go to an inbox nobody checks.
- Cloud-only files, app databases, or metadata are missing from the backup plan.
Adopt, Pilot, Defer, Avoid
- Adopt: Adopt the design when it separates working data, local recovery, and offsite or offline recovery.
- Pilot: Pilot with one folder, one app export, or one photo subset before reorganizing the whole data set.
- Defer: Wait when the current setup is stable, backed up, monitored, and the proposed change is mostly curiosity.
- Avoid: Avoid treating RAID, snapshots, sync, or cloud drive alone as a complete backup plan.
Validation Checklist
- Upload test photos from every phone in the household.
- Restore the Immich database and library to a test location before trusting it.
- Export a Google Takeout sample and confirm timestamps and metadata behavior.
- Confirm offsite backup includes originals and database dumps.
- Train family members on what is backed up and what is only synced.
Common Mistakes
- Treating Immich as the only copy of photos.
- Importing a full Takeout archive without a small pilot.
- Ignoring database backup.
- Letting phone battery restrictions break uploads.
- Deleting the cloud copy before restore testing.
Troubleshooting
| Symptom | Likely Cause | First Check |
|---|---|---|
| Restore fails | Backup captured files but missed app state, permissions, keys, or database exports. | Restore to a clean folder or VM and compare timestamps, permissions, and app behavior. |
| Storage feels slow | Network, disks, protocol overhead, Wi-Fi, or client limits are the real bottleneck. | Test wired transfer speed, disk health, and client link speed separately. |
| Backups look successful but feel risky | Jobs report completion without proving recovery. | Schedule a restore drill and record exactly what did and did not come back. |
Maintenance Cadence
A photo system quietly accumulates new phones, albums, storage, and credentials. Put upload checks, database backups, offsite-copy age, capacity review, and a representative restore on the calendar so family-photo recovery does not depend on one administrator remembering every dependency.
- Monthly: Check backup job status, drive health, free space, and the age of the newest offsite copy.
- Quarterly: Restore a real folder or app export to a clean location and confirm permissions, metadata, and versions.
- Yearly: Review capacity, replace aging drives or UPS batteries as needed, and confirm the offsite copy still matches the risk.
Photo maintenance must pair job status with a restore. A green database dump and a successful file copy do not show that they represent the same point in time, that encryption keys are reachable, or that the restored Immich release can reconnect records to originals. Rehearse that relationship, not just each backup command.
When To Spend Money
Buy photo-storage hardware only after the pilot identifies a measured constraint: insufficient protected capacity, slow restore, missing drive bays, inadequate network throughput, or no power-loss handling. A new NAS does not repair an untested backup or a metadata migration plan.
| Stage | Signal | Practical Buying Guidance |
|---|---|---|
| Do not buy yet | Restore has not been tested, data has not been tiered, or the existing bottleneck is unknown. | Spend time on inventory, restore proof, labels, and documentation before buying another enclosure. |
| Small useful spend | Backups are working but the weak point is power, replacement media, or offsite transport. | UPS with shutdown signaling, external backup drive, spare drive, drive labels, or a safe storage case. |
| Larger upgrade | Capacity, restore time, drive bays, network throughput, or app-data reliability is now a measured constraint. | NAS, larger disks, 2.5GbE/10GbE path, offsite target, or a separate compute host. |
Useful Gear And Buyer Notes
The product links below are intentionally search links, starting with 4 bay NAS for photos, because model numbers, bundles, and prices change quickly. Use them to compare categories, then verify exact specifications against the article's decision points before buying. For infrastructure gear, prioritize firmware support, replaceability, warranty, idle power, and recovery behavior over headline specs.
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.
- Amazon search: 4 bay NAS for photos
- Amazon search: NAS hard drive 12TB
- Amazon search: mini PC home server
- Amazon search: external hard drive photo backup
- Amazon search: UPS for home server
Related TechGeeks resources
- Homelab Backup Strategy: NAS, Offsite Copies, and Restore Tests
- How to Build Cheap Offsite Backup at a Friend or Family Member's House
- The 3-2-1 Backup Rule in 2026: Keep It, But Add Two Checks
Security, Privacy, Legal, Recovery, and Evidence Limits
Security and privacy boundaries: Restrict Immich administration, patch the host, protect database credentials, and encrypt backup destinations where appropriate. Self-hosting changes who operates the service; it does not remove sensitive faces, locations, device metadata, or sharing links. Google Photos adds a provider and account-recovery dependency, while Immich adds a household administrator and network-exposure dependency.
Legal and recovery boundaries: Export, retain, and share only photos you are entitled to handle, and account for consent when facial recognition, location history, or family libraries involve other people. Keep the old library and cloud copy until a separate backup of originals, metadata, database state, and credentials has been restored into a disposable environment.
What the evidence does not prove: Successful uploads from a few phones do not prove every background-sync policy will remain reliable. A database dump does not prove originals are present, a Takeout sample does not prove a full migration will preserve every album or edit, and a RAID or snapshot status does not prove recovery from account loss, ransomware, theft, or site loss.
Practical FAQ
Is Immich ready to replace Google Photos?
Google Photos wins on low-friction mobile backup, sharing, and search. Immich wins when you want local control, self-hosting, and independence from a cloud-photo subscription. Both still need backup. A photo app is not the same thing as a recovery plan. The important next step is to validate the recommendation with one small test before treating it as the default.
How do I migrate Google Takeout data without losing metadata?
Choose controls against named photo-loss events. A mirror can keep service running after one disk fails, retained snapshots may reverse an accidental deletion, an offline copy can survive ransomware, and a separately recoverable export can reduce cloud-account dependence. None substitutes for opening restored originals and metadata from the recovery path.
What backup plan is required before trusting self-hosted photo storage?
For photos, keep working originals, a quick local restore, and protected history beyond the reach of the same administrator or sync job. Test the chain with a known image and its metadata; otherwise three destinations may still be three synchronized copies of the same corruption.
References
- Google Photos: Back up photos and videos
- Google Account Help: Download your data
- Immich: Backup and restore
- Immich: Mobile backup
- CISA: How to Protect Data Stored on Your Devices
Community discussion sources used for topic selection and reader-question framing:
- https://www.reddit.com/r/homelab/comments/1ser08o/need_to_wean_myself_off_of_google_photos/
- https://www.reddit.com/r/homelab/comments/1odx36g/moving_200gb_from_google_photos_to_immich_need/
Final Thought
Use Google Photos if you want convenience. Use Immich if you want control. Use backups either way.
Need help applying this?
Bring TechGeeks into the real environment.
If you are working through this on a live network, WordPress site, Linux server, AI workflow, or PisoWiFi deployment, send the context and we can help turn it into a practical plan.
