Immich
💡 快速導航
Immich 是我家目前主要的手機相片備份與家庭相簿中心。它的定位不是單純「架一個 Google Photos 替代品」，而是把每天產生的照片、影片和回憶留在自己可控的儲存環境裡。
在整套 Home Lab 裡，Immich 屬於少數我選擇放在 TrueNAS 上的服務。原因很直接：相片與影片資料量大、縮圖和機器學習任務吃 CPU / iGPU，而且資料本身就在 NAS 上，讓服務靠近資料比跨主機掛載更穩定。
🎯 我為什麼用它
不想把所有照片都綁在商業雲端
手機相片是最不想遺失、也最容易不知不覺累積大量資料的東西。如果全部放在 Google Photos 或 iCloud，使用體驗很方便，但長期會遇到幾個問題：
- 容量費用會隨著家庭成員與年份持續增加
- 匯出大量照片時不一定順手
- 相片、影片和 metadata 不完全在自己掌控之中
- 家人每台手機各自備份，整體狀態很難集中確認
Immich 解決的是「手機拍完之後，自動回到家裡」這件事。它讓照片先落到自己的儲存系統，再由我自己決定怎麼備份、保留和整理。
手機容量焦慮真的會下降
Immich 對我最有感的地方，是降低手機容量壓力。手機拍照後會自動上傳，之後可以在時間軸回看，不需要一直把照片留在手機本機。
這不是要完全取代手機相簿 App，而是讓手機不再是唯一副本。
🧱 為什麼放在 TrueNAS
我一開始規劃 Home Lab 時，大多數服務都放在 OMV 的 Docker 環境，讓 OMV 作為 App Layer。但 Immich 是例外之一。
flowchart TD P[手機 / 平板] --> RP[反向代理 / HTTPS] RP --> IM[Immich<br/>TrueNAS] IM --> DB[(Database / Metadata)] IM --> ML[Thumbnail / ML Jobs] IM --> DATA[(RaidZ2/DataPool/Immich)] DATA --> BK[OMV Backup Target]
主要原因
| 考量 | 放在 TrueNAS 的原因 |
|---|---|
| 資料靠近性 | 原始照片與影片直接在 NAS dataset 上，避免大量資料跨 NFS 來回讀寫 |
| 縮圖與影片處理 | Immich 需要做縮圖、轉碼或機器學習相關工作，TrueNAS 主機硬體比較適合 |
| 長期容量 | 相片資料會持續成長，放在主要 ZFS pool 上比較容易搭配快照與容量規劃 |
| 維運邊界 | Immich 的資料屬於家庭核心資料，不只是一般 App cache |
這也讓整套架構變成：大多數服務跑在 OMV；少數需要靠近資料或硬體能力的服務跑在 TrueNAS。
📱 我的實際使用方式
目前 Immich 的角色很單純：
- 手機拍照後自動同步備份到家裡
- 作為家庭相簿中心
- 透過時間軸快速回看過去照片
- 集中管理家人手機上傳的相片與影片
我不把 Immich 當成一次就整理完所有歷史照片的專案，而是先讓「每天新增的照片」穩定進來。只要日常上傳可靠，後面再慢慢整理舊照片、相簿和人物分類，壓力會小很多。
使用體驗
| 面向 | 實際感受 |
|---|---|
| 手機備份 | 自動上傳後比較不用擔心手機遺失或容量不足 |
| 回看照片 | 時間軸瀏覽直覺，找最近幾天或幾個月的照片很方便 |
| 家庭使用 | 家人資料集中後，比每個人各自散在手機或雲端更好管理 |
| 維運壓力 | 儲存與備份要先想清楚，否則越用越難搬 |
💽 儲存與資料規劃
Immich 最重要的不是 Web UI，也不是 App，而是資料規劃。
目前我把 Immich 的主要資料放在 TrueNAS 的資料池中：
RaidZ2/DataPool/Immich這個 dataset 屬於長期保存資料，不應和可隨時重建的暫存 cache 混在一起。Immich 裡需要保護的資料大致分成三類：
| 類型 | 重要性 | 說明 |
|---|---|---|
| 原始照片 / 影片 | 最高 | 手機上傳後的核心資料，遺失就無法重建 |
| Database / metadata | 最高 | 相簿、使用者、上傳狀態、asset 關聯都依賴 DB |
| 縮圖 / cache | 中 | 可重建，但重建會花時間與 CPU |
Important
只備份照片檔案不等於完整備份 Immich。Database 和上傳資料的對應關係同樣重要，否則還原後可能會遇到資料存在但系統狀態不一致的問題。
🔁 備份與風險控管
Immich 是我會優先納入備份策略的服務，因為它保存的是家庭記憶，不是壞掉重建就好的工具。
我的整體備份方向是：
- TrueNAS 保存主要資料
- OMV 作為獨立備份落地點
- 重要資料透過排程同步到 OMV 的備份硬碟
- 服務更新前先確認有可回滾的資料狀態
備份時我會特別注意
- 照片原始檔要有第二份副本：不能只依賴單一 pool。
- Database 要和檔案一起保護：兩者時間點差太多，還原時容易不一致。
- 還原流程要演練：沒有做過 restore drill 的備份，只能算「可能有用」。
- 不要把同步誤當備份：手機自動上傳只是 ingestion，不代表已經完成備援。
我不會做的事
- 不把 Immich 當作唯一照片保存位置
- 不在沒有備份前大量匯入歷史照片
- 不用
latest盲目更新核心服務 - 不只看容器有沒有啟動，還要確認 App、DB、上傳和瀏覽都正常
⚠️ 我踩過的坑
容量成長比想像快
照片服務最容易低估的就是容量。剛開始只看手機相簿可能覺得還好，但只要加入影片、Live Photo、多位家庭成員、歷史照片匯入，成長速度會明顯變快。
所以 Immich 上線前，我會先想：
- 目前一年大概產生多少照片與影片？
- 家人加入後容量會增加幾倍？
- pool 剩餘容量能撐多久？
- 備份端是否也有足夠空間？
先規劃，再邀請家人加入
Immich 一旦給家人使用，就不只是自己的玩具服務。更新、停機、備份失敗都會影響其他人。
比較穩的做法是：先讓自己的手機穩定跑一段時間，確認上傳、備份、更新和還原流程都沒問題，再邀請家人一起用。
相片服務不是只有 App 資料夾
很多服務壞了，保留 config 就能重建。但 Immich 需要同時理解：
- app data
- upload library
- database
- thumbnails / generated files
- machine learning 產生的索引或 metadata
這些東西的重要性不一樣，備份策略也不能全部用同一種方式處理。
⬆️ 升級與維運原則
Immich 發展很快，功能進步明顯，但也代表升級時不能太隨意。
我的升級原則：
- 先看 release note，特別注意 breaking changes、DB migration 和 mobile app 相容性。
- 更新前先確認備份狀態，必要時做額外 snapshot。
- 一次只升級 Immich 相關服務，不和其他核心服務一起混著更新。
- 更新後檢查登入、時間軸、上傳、縮圖、影片播放與背景 job。
- 保留前一版 image tag 或可回滾狀態，避免升級失敗只能硬修。
日常巡檢項目
- 手機是否持續自動上傳
- 磁碟容量成長是否符合預期
- 備份任務是否成功
- Database / metadata 是否有正常納入備份
- 縮圖與背景工作是否卡住
- 家人是否有遇到登入或同步問題
結論
Immich 是我 Home Lab 裡最有生活感的服務之一。它不只是技術展示，而是每天真的在幫我把手機照片帶回家、減少手機容量焦慮，並讓家庭相簿不再完全依賴商業雲端。
但它也不是「架起來就好」的服務。真正重要的是先想清楚資料放哪裡、怎麼備份、怎麼還原，以及家人加入後誰會受到影響。