NAS 上的 Immich：告别 iCloud 照片订阅

早上九点，我在 NAS 上打开 compose 文件，目标很具体：今晚睡觉前，自己的手机先把后台上传跑起来；周末再让家人装 App。iCloud 照片订阅年年涨，原图却始终想落在自己磁盘上。Immich 是我试过的自托管相册里最接近「能给非极客家人用」的——有官方 App、有时间线、人脸可关，上传体验不像 Nextcloud 那样劝退。下面按真实时间线写这一天。

09:00 拆卷，而不是先点 up

官方 compose 一拉就能起来，但长期跑要先想清楚三块磁盘语义，而不是默认全部塞进同一个 volume。

上传原图目录最大，直接挂 NAS 数据池，例如 /data/immich/library。Postgres 数据不能和原图混在同一套「随便 rsync 一下」的策略里，它需要可单独做一致性备份的路径。机器学习模型与缩略图缓存可以重建，丢了能扫库再生，但重建很耗 CPU 和时间，单独挂卷便于以后迁移时选择「只搬原图 + 库」。

机器建议 16G 内存起步。第一次识别人脸、生成缩略图会把 CPU 打满，别和游戏服抢同一台已经偏热的小主机。.env 里改好 UPLOAD_LOCATION、数据库密码、时区；反代挂 HTTPS（Traefik、1Panel、Caddy 任一）。手机 App 对自签证书很挑剔，正规域名证书能省掉大半排错时间。

外网我套 Cloudflare Tunnel + Access，不把 Immich 直接裸奔在公网端口。局域网用内网域名解析到 NAS，减少绕 CDN 上传的流量费和延迟——家人在家连 Wi-Fi 传几千张历史图时，这一点体感差别很大。

11:30 容器起来，先自测再谈手机

docker compose up -d 后盯日志，确认 Postgres 健康、immich-server 与 microservices 不再重启。Web 用浏览器登录管理员账号，建好自己的用户，顺手关掉公开注册。上传一张本地测试图，看时间线是否出现、缩略图是否生成。若缩略图队列堆积，先看机器是否在同时跑识别任务，必要时错开「白天传图、夜间跑机器学习」的节奏，避免小主机热到降频。

这时不要急着装家人手机。我把 HEIC、一张 Live Photo、一段短视频各丢一次，确认没有「能传不能看」。人脸分组暂时保持关闭——家庭相册里「谁和谁常一起出现」有时是趣味，有时是隐私包袱，等和家人对齐后再说。

14:00 自己的手机先吃历史库

装官方 App，服务器地址填 HTTPS 域名，打开后台上传。第一周本质是历史照片灌库：电量和发热会明显，插电、连家里 Wi-Fi、建议「仅 WLAN」甚至「仅充电时上传」，按机型习惯选。Android 与 iOS 后台限制不同，小米、华为可能要手动允许自启与不受电池优化。

我让自己的手机先跑一整晚。顺序必须是：上传确认无异常 → 再谈是否关闭 iCloud 照片。反过来会空窗，家人一有「手机里找不到去年旅行」的恐慌，自托管项目就容易被否决。

18:00 备份策略写进清单，不是写进心情

Immich 进程挂了可以重装；库没了就是真没了。当天傍晚我把策略落成可执行的几条，而不是「回头再说」：

数据池快照（ZFS / TrueNAS）：防误删、防软件 bug 扫库
restic 异地：防火灾和整池灾难
数据库用官方流程或 pg_dump，与 library 目录分开保留

恢复演练做过一次才敢安心：空实例 → 还库 → 挂 library → 触发扫库 → 随机打开一年前的照片确认能下原图。没演练的备份只是安慰剂。升级 Immich 前同样先快照再 pull：读 release note 里的数据库迁移，App 强制更新有时要求最低服务端版本，月更一次比追 nightly 稳。

21:00 给家人装之前的话术

晚上给家里人装时，我只强调三件事：地址我配好了、插电连家 Wi-Fi 过夜、前几天手机会有点热。不讲 compose，不讲人脸模型。共享相册给远端亲戚用限时链接或只读用户，不为了方便开全局注册。