Immich 自建相册实测：能不能替代群晖 Photos

家里群晖 NAS 用了几年，Photos 里的照片从几千涨到了几万张。最近家人开始抱怨：手机备份经常漏、找人脸照片要翻半天、AI 识别的准度也不太行。趁这个机会，我在群晖上用 Docker 部署了开源的 Immich，实测跑了两周——这篇就说说它能不能替代群晖 Photos、部署过程和从 Photos 迁移过来的成本。

先说结论：Immich 是干什么用的

Immich 是一个开源的自托管照片/视频备份方案，号称"Google Photos 自建版"。它和群晖 Photos 最大的区别有三点：

1. 多端备份更主动：iOS / Android 客户端有真正的后台备份，定时任务、仅 Wi-Fi、仅充电等策略都有；
2. AI 能力更强：内置人脸识别、语义搜索（比如搜"海边""狗"直接出图）、地图时间线，用的都是本地模型，不上传云端；
3. 权限更开放：支持多用户、共享相册、相册链接分享，API 完善，第三方客户端和插件多。

如果你只是要一个"NAS 上存照片"的地方，群晖 Photos 够用了。但如果你要的是全家人手机自动备份 + 能按人脸/场景快速找回，Immich 值得一试。

Docker 一键部署：群晖 Container Manager 实战

Immich 官方提供 docker-compose 部署，一共 4 个核心容器：服务端（server）、PostgreSQL 数据库、Redis、机器学习服务（machine-learning）。群晖 DSM 7.2 的 Container Manager 直接支持 compose 项目，步骤如下：

第 1 步：准备共享文件夹

在 File Station 建两个共享文件夹（或同一文件夹下的子目录）：

• /docker/immich —— 放配置文件和数据库数据
• /volume1/photo/immich-library —— 放真正的照片库（建议和 Photos 用同一个 volume 但不同目录，方便迁移对比）

第 2 步：写 compose 文件

去 Immich 官网 release 页下载官方的 docker-compose.yml 和 .env 模板（官网有完整文档，本文用当时最新版 v1.1xx）。核心配置注意这几项：

services:
  immich-server:
    container_name: immich_server
    image: ghcr.io/immich-app/immich-server:${IMMICH_VERSION:-release}
    volumes:
      - ${UPLOAD_LOCATION}:/data          # 照片实际存储路径
      - /etc/localtime:/etc/localtime:ro
    env_file:
      - .env
    ports:
      - 2283:2283
    depends_on:
      - redis
      - database
    restart: always

.env 里关键的几项：

UPLOAD_LOCATION=/volume1/photo/immich-library
DB_PASSWORD=改一个强密码
IMMICH_VERSION=release

第 3 步：Container Manager 建项目

Container Manager → 项目 → 新增 → 输入项目名称 immich，把 compose 文件内容粘贴进去，建好后启动。第一次启动会拉 4 个镜像，大约 2~3 GB，群晖的千兆内网一般几分钟拉完。

启动成功后浏览器打开 http://群晖IP:2283，先注册管理员账号（第一个注册的就是管理员），然后就可以建用户、装手机 App 扫码登录了。

第 4 步：挂载已有照片目录

如果你 NAS 上已经有整理好的照片目录（比如 Photos 的备份文件夹），可以直接把目录映射进容器，然后在后台"外部库（External Libraries）"里添加，Immich 会扫描入库，不复制文件。这是我从 Photos 迁移时最省事的一步，下面迁移部分细说。

两周实测：和群晖 Photos 对比体验

我拿了同一批约 1.2 万张照片 + 800 个视频做对比，结论先行：

几个实测细节：

1. 备份可靠性：iPhone 上 Immich 的后台备份两周零漏传；Photos 之前平均每周漏 2~3 天，得手动点开 App 触发。这对"给爸妈备份"这个场景是决定性差距。
2. 人脸识别速度：DS920+ 上 1.2 万张照片的初始识别跑了约 6 小时（CPU 满载），之后增量识别无感。识别准度上，同一人的不同年龄段照片基本能聚到一起，Photos 那边我手动合并了几十次。
3. 视频回放：Immich 默认会转码生成预览，手机端滑动时间线很跟手；原画质点开即看。HEVC 视频在部分旧安卓机上需要转码，NAS CPU 弱的话会有点卡。
4. 搜索体验：搜"身份证""发票"这种文档类照片，Immich 的 OCR + 语义搜索基本能命中，Photos 只能靠文件名和时间。

避坑：部署前必须知道的 5 件事

1. 内存至少 4GB 可用：machine-learning 容器吃内存，2GB 内存的入门 NAS（如 DS220j 这类）别折腾，会卡到怀疑人生。DS920+ / DS923+ 这种 4GB 起步的没问题。
2. 数据库密码别用特殊字符：DB_PASSWORD 里如果有 # ! 这类字符，compose 解析可能出问题，用纯字母数字最稳。
3. 照片目录权限：容器内默认用 UID 1000 读写，群晖上给共享文件夹的读写权限时，注意勾选"应用到子文件夹"。权限不对的表现是上传 0 字节文件。
4. 版本升级别追 latest 太快：Immich 迭代快，偶尔有 breaking change。生产库建议锁 IMMICH_VERSION 为具体版本号，升级前先看 release notes，有数据库迁移的一定先备份。
5. 备份 Immich 的数据库：照片文件在 /data 里好备份，但人脸标注、相册关系都在 PostgreSQL 里。定期用 pg_dump 导出一份，或者把 database 容器的数据卷纳入 Hyper Backup。

从 Photos 迁移过来，成本有多大

这是大家最关心的。我实测的迁移路径：

1. 照片文件：Photos 的照片实际存在 /photo 下（按时间分目录），直接把该目录映射为 Immich 的外部库，扫描入库，零复制、零耗时（除了 AI 识别那几小时）。
2. 相册关系：Photos 里的相册不会自动过来。我的做法是：重要的家庭相册（大概 30 个）在 Immich 里重建，用"按条件筛选 + 批量加入"的方式，两个人一下午搞定。不重要的相册直接放弃——迁移是个断舍离的好机会。
3. 人脸标注：Photos 的人脸数据导不出来，Immich 要重新识别。这是最大的一次性成本，但识别完准度更高，算值得。
4. 分享链接：Photos 的旧分享链接会失效，提前通知家人换新链接。

总成本：一下午的人工 + 一晚上 AI 识别的电。迁移完我把 Photos 保留为"冷备份"，Immich 作为日常主力。

怎么卸载：不喜欢就干净撤走

Immich 是纯 Docker 部署，卸载非常干净：

1. Container Manager 里停止并删除 immich 项目（勾选"同时删除容器"）；
2. 删掉 /docker/immich 配置目录（数据库数据在这里）；
3. 照片库目录 /volume1/photo/immich-library 如果是外部库映射的，不要删，那是你的原照片；
4. 手机 App 卸载即可。

整个过程不碰 DSM 系统，Photos 的数据完全不受影响，可以随时回滚。这也是我敢拿主力照片库做实测的原因。

总结：谁适合换，谁没必要

• 适合换：家人多、手机备份老是漏、人脸/场景搜索是刚需、NAS 内存 4GB 以上。
• 没必要换：就自己一个人用、照片量不大、Photos 用得挺顺手、NAS 是入门款。

我自己的选择：Immich 主力 + Photos 冷备份，两条腿走路。毕竟照片这东西，丢一次的教训比什么都贵。

相关旧文

• 群晖 3-2-1 备份方案：Hyper Backup + 快照 + 异地备份一次配好 —— Immich 的数据库记得纳入备份计划
• Dockhand 开源 Docker 可视化管理面板：群晖 NAS 一键部署实战 —— 容器管理更顺手
• Komari 轻量服务器监控：Docker 一键部署 + 与 Uptime Kuma 区别详解 —— 顺手监控下 NAS 负载