自建相册 Immich：部署、相册结构与手机备份的实测记录

把十年照片交给云厂商，心里总有点不踏实；但自建相册又要面对索引慢、人脸识别吃 CPU、外网访问配置麻烦这些现实问题。

Immich 的架构分成 server、machine-learning、PostgreSQL、Redis 四块，跑起来不难，难在长期维护和数据安全。

先说结论

4 核 8G 起步，机器学习容器可只用 CPU，备份按「原图 + 数据库」两份做。

• 照片原图存本地目录，数据库单独备份
• 机器学习容器首次索引会跑满 CPU，安排在夜间
• 外网访问走反代 + HTTPS，别直接暴露端口
• 每月验证一次恢复，尤其是数据库

先把问题说清楚

Immich 把元数据放 PostgreSQL，原图放在 UPLOAD_LOCATION。数据库丢了，人脸、相册、时间线全丢，原图还在但组织关系没了。

所以备份必须包含数据库 dump，而不是只同步照片目录。

具体怎么做

按顺序执行，每步都验证完再进下一步：

• 准备目录：上传目录、数据库目录、模型缓存目录分别挂载
• 写 compose：server + machine-learning + postgres + redis，固定版本 tag
• 设置时区与 UPLOAD_LOCATION，启动后先跑一次完整索引
• 手机装 App 开启后台备份，仅 Wi-Fi、仅充电时同步
• 配反向代理与 HTTPS，限制上传大小，开双因素认证

参数与成本对照

把关键数值摊开，方便判断该选哪条路：

几个容易踩的坑

下面这些是最常见的错误做法：

• 只同步照片目录不备份数据库：相册结构全丢
• 索引时限制 CPU 太狠：几万张要跑几天
• 外网直接映射 2283 端口：被扫到就是风险
• 手机备份不开「仅 Wi-Fi」：流量爆掉

最后补两句

自建相册的长期成本不在部署，在「数据不丢」和「换机器能迁走」。这两点想清楚再上车。

工具是手段，理解机制才是能力。命令记不住没关系，知道「该看什么」就够了。