用 Immich 把全家照片搬回 NAS：自建家庭相册的部署、备份与避坑

摘要： 云盘越用越贵、隐私越来越悬，本文记录我在 NAS 上用 Immich 自建家庭相册的完整过程——从目录规划、Docker Compose 部署、手机自动备份，到人脸相册整理与 3-2-1 备份，并总结了最容易踩的 6 个坑。

为什么要把照片从云盘搬回本地

用了几年某云盘家庭相册，越用越别扭：免费空间见底后年费年年涨；原图压缩、视频限清晰度；最关键是全家人的人脸和定位数据都躺在别人服务器上。NAS 本来就是家庭数据中枢，把照片也收回来，既省长期订阅费，又能保留原画质，数据还完全自己掌控。Immich 是这两年最像样的开源替代：界面接近 Google Photos，支持手机自动备份、人脸识别、地图相册、共享相册，服务端跑在 Docker 里，对 NAS 友好。

部署前的准备：硬件与目录规划

Immich 的机器学习（人脸识别、物体识别）比较吃资源，建议 NAS 是 x86 架构、内存 4G 以上（8G 更稳），ARM 小机器也能跑但识别会慢。存储上单独划一个共享文件夹，比如 /volume1/photo，下面再分三层：

library/：原始照片和视频的存放地，Immich 不会改动这里的文件，只建缩略图；
upload/：手机端上传的临时落盘区；
postgres/：PostgreSQL 数据库卷，存的是元数据、人脸、相册关系，丢了就只剩一堆无名文件。

目录分清楚，后面备份和迁移才不会乱。

用 Docker Compose 一键拉起

在 NAS 的 Docker 项目里新建 docker-compose.yml，核心是两个服务：Immich 主程序和一个 PostgreSQL 数据库（官方已不再内置数据库）。精简版要点：

immich-server 挂载 /volume1/photo/library:/usr/src/app/upload 和 upload 目录，端口映射 2283:3001；
database 用官方 postgres 镜像，挂载 postgres/ 卷，务必设强密码并记到密码管理器；
环境变量 IMMICH_SERVER_URL、上传根 UPLOAD_LOCATION 按实际填。

docker compose up -d 后等镜像拉完、数据库初始化，访问 http://NAS内网IP:2283 就能看到登录页。第一次进入务必在「管理」里关掉开放注册（或只设强管理员），否则公网一开谁都能建账号。

首次配置与手机自动备份

建好管理员账号后，先到「用户设置 → 存储模板」把上传路径规则定好（按 年/月/原文件名 最直观）。手机装 Immich App，登录内网地址，开启「自动备份」，建议只勾选「相机」和系统相册，别把微信缓存图也传上去。第一次会全量上传，几百 G 建议插 WiFi 慢慢跑；之后是增量，只传新图。

人脸识别与相册整理

后台跑完机器学习任务后，「人物」页会出现自动聚类的人脸，逐个改名即可生成人物相册；「地图」页按拍摄定位把照片铺在地球上，旅行照一目了然。这里有个坑：人脸模型默认用英文，中文名搜索没问题，但识别准确度跟照片质量强相关，模糊合影容易分错，定期「合并/拆分」即可。

备份策略：别让"自建"变成"裸奔"

自建相册最大的陷阱是忘了备份——一旦 library 或数据库损坏，照片可能找不回来。我的做法：

库文件每天增量同步到一块外接硬盘（Hyper Backup 或 rsync）；
PostgreSQL 每周 pg_dump 导出 SQL，和库文件放一起；
重要年份的照片再冷备一份到异地（亲戚家 NAS 或加密云盘）。

记住：缩略图可以重建，原图和数据库才是命根子。

最容易踩的 6 个坑

公网暴露没加 HTTPS，手机在外网连不上——用反向代理配证书；
上传大视频不转码直接占满上传带宽，App 里限个速率；
机器学习吃满内存导致 NAS 卡死，给容器设内存上限；
版本升级不读发布说明，数据库 schema 变了起不来——升级前先备份；
忘了关注册，被扫到开放注册；
把 upload 和 library 挂同一个目录，整理时误删原图。

小结

把全家照片搬回 NAS 不是折腾，而是一次长期的隐私和成本优化。Immich 现在成熟度已经够日常用，部署半天、备份一小时，换来的是原画质、零订阅和完全自主。下一步可以接电视端看照片墙，或把家人的共享相册也迁进来。