Immich vs Google Photos: Which Photo Backup Setup Should You Trust?
Tech GuruQuick Answer
Choose Google Photos when you want a provider-operated photo service and accept its account, export and storage policies. Consider Immich when someone will maintain the server, updates and recovery copies. Before replacing either library, test every phone, a representative metadata export and an isolated restore. Neither automatic upload nor a database dump alone proves that irreplaceable photos can be recovered.
Design principle: Separate working data, local recovery, and offsite recovery. One box can help, but one box should not be the whole plan.
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 Operates for You
With Google Photos, the provider operates the photo service rather than a household server administrator. Evaluate whether its upload, search and sharing behavior meets the household's needs on the actual devices; this guide contains no controlled usability or upload-speed comparison.
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
The Immich backup guide distinguishes database dumps from photo/video files: automatic database backups contain metadata, not the media itself. Protect both the matching database state and files under the configured upload location, plus external-library sources and deployment configuration. Copy these backups outside the host. A dump retained on the same failed storage is not independent recovery.
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.
| Household Requirement | Pilot Check | Keep the Old Path When |
|---|---|---|
| Each phone uploads reliably | Selected albums, network policy, background restrictions and new-item arrival. | An enabled switch is the only evidence that uploads finished. |
| Dates and organization remain useful | Representative capture times, edited items, videos, albums and exported metadata. | An importer reports success but required metadata is absent. |
| Sharing reaches the right people | Actual recipient access and a denied-account test. | Link visibility or household consent is unclear. |
| Someone can recover the library | Independent copy, credentials and matched database/media restore. | Only the original administrator or live host can open it. |
| Capacity and maintenance are affordable | Original growth, backup history, server/storage costs and update responsibility. | The plan budgets only the gallery host, not recovery. |
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.
Illustrative Family Pilot
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 | Investigate | Safe Next Step |
|---|---|---|
| New phone photos are missing | Selected albums, Wi-Fi policy, app permissions, battery settings and server reachability. | Check upload status and reopen the app; retain the phone originals and previous backup path. |
| Capture dates look wrong after import | Embedded metadata versus filesystem dates and sidecar handling. | Compare an untouched source sample with the imported item before changing any metadata. |
| Database restore succeeds but media is missing | Matching original files, external-library paths, upload mounts and backup time. | Stop the isolated rehearsal and reconcile the recovery set; do not point it at live writable originals. |
| Restore instructions differ from the installed release | Backup source version, target version and versioned project documentation. | Use a compatible disposable target and documented sequence; database restore overwrites target state. |
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
This comparison is documentation-backed. TechGeeks did not request a Takeout export, run an importer, measure mobile upload reliability or restore Immich for this revision. Immich restore procedures can replace the target database; rehearse only against isolated storage and use documentation matching the backup and target release.
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?
Immich is a candidate when the household can operate it and the pilot meets its upload, sharing, metadata and recovery requirements. Keep Google Photos or another verified path active while those checks remain unresolved. Readiness depends on the specific household and installed release, not a general feature comparison.
How do I migrate Google Takeout data without losing metadata?
Keep the untouched Takeout archive and all of its parts, including JSON sidecars. Google notes that downloaded file timestamps can differ from embedded capture metadata, while additional Photos metadata may be in JSON. Test the selected importer on copies of a small representative set and compare dates, edits, albums and ownership in the destination. Do not bulk rewrite or deduplicate the only originals. No importer or sample export guarantees full metadata fidelity.
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.
