Immich 已经到 v3.1：自建“私人 Google Photos”省下订阅费之前，你先接手了备份、升级和安全责任
Immich 很容易被一句话概括：“一个开源、免费、自托管的 Google Photos 替代品。” 这句话只对了一半。 截至 2026 年 8 月重新核验，Immich 已经进入 v3 系列：v3.0.0 在 7 月 2 日发布，7 月 29 日又到了 v3.1.0。当前项目支持移动端自动备份、RAW、多账号、搜索、面部识别与聚类、地图、共享、OAuth、API Keys、工作流等大量能力。 它
Immich 已经到 v3.1：自建“私人 Google Photos”省下订阅费之前，你先接手了备份、升级和安全责任
Immich 很容易被一句话概括：“一个开源、免费、自托管的 Google Photos 替代品。”
这句话只对了一半。
截至 2026 年 8 月重新核验，Immich 已经进入 v3 系列：v3.0.0 在 7 月 2 日发布，7 月 29 日又到了 v3.1.0。当前项目支持移动端自动备份、RAW、多账号、搜索、面部识别与聚类、地图、共享、OAuth、API Keys、工作流等大量能力。
它已经不是一个“极客相册Demo”。
但这也意味着：你真的可以把家庭最重要的一批私人数据交给它时，问题就不再是“能不能跑”。
而是：坏盘怎么办？数据库坏了怎么办？升级失败怎么办？手机以为备份了但实际上没传完怎么办？账号被打怎么办？恢复过吗？
Self-hosted 的真正含义，是把一部分云厂商的责任接到自己手里。
一、先纠正一个版本问题：Release 页面必须现核
原始素材写“近期 v3.0”。如果只看某些搜索快照，你甚至可能看到旧版本仍被缓存成 Latest。
但继续核官方发布记录，会发现：v3.0.0：2026-07-02；v3.1.0：2026-07-29。
这正好是我们一直强调的 Release Freshness Gate。
开源项目的 README crawl、搜索缓存、Release 页面、Announcement 可能不同步。写教程不能把一个月前的“即将发布”继续写成当前状态。
而 v3 还是 major release，升级意味着兼容与迁移责任。因此 Immich 不是那种“装一次五年不动”的工具。
二、Immich当前真正强在哪里
1. 移动端备份体验已经很接近云相册逻辑
手机选择相册、后台备份、Live Photo / Motion Photo、重复上传防护、多种图片/RAW支持。
这决定了它不是单纯的Web图库。一个家庭照片系统如果每天都需要手工拖文件，基本坚持不久。
2. 搜索与本地机器学习
项目当前支持按元数据、对象、人物、人脸和 CLIP 等方式搜索。
这类能力让自托管不再意味着“只能按文件夹找图”。但要注意：人脸识别、语义搜索的存在不等于准确率对所有家庭和硬件一样；本地跑机器学习也不意味着整个系统没有任何外部数据面，OAuth、地图、第三方集成都需要分别看配置。
3. 多用户、分享、地图、回忆等
这些功能意味着它开始承接一个真正的“家庭媒体系统”，而不是个人NAS里的一块目录。也正因为如此，权限问题的后果更大。
三、“照片存自己服务器”并不等于“照片安全”
这里是自托管最常见的逻辑跳跃。
Ownership ≠ Durability。
你控制硬盘，不代表硬盘不会坏。你控制服务器，不代表勒索软件进不来。你没有第三方云盘，不代表数据库不会损坏。
最危险的一种状态是：手机照片删掉了；Immich里看得到；用户因此以为“已经有备份”；但服务器其实只有一块盘。
那不是备份，只是搬家。
四、3-2-1只是起点，恢复测试才是终点
一个认真使用的家庭照片库，我至少会画出四层：
Primary：Immich 主存储。
Local Secondary：另一块独立介质或设备上的副本。
Offsite：异地或离线副本，防火灾、盗窃、勒索软件和整机损坏。
Restore Test：定期抽样恢复数据库和照片。
很多人前三项都做了，却从没恢复过。真正出事时才发现：备份任务几个月前就停了；数据库版本对不上；密钥没备份；文件在，元数据没了；或者备份本身也被加密了。
所以我们把“备份”升级成：Recoverability。
五、v3最大的提醒，不是新功能，而是升级责任
Major release 往往伴随 breaking changes、API或依赖迁移。
这告诉我们：Self-hosted 成本里必须有 Update Debt。
如果你不升级，安全漏洞和兼容性债务积累；如果你升级，需要备份、读 release notes、看 migration、检查移动端/服务器版本兼容。
云服务把很多这类工作藏在后台，自托管把它们还给你。
六、安全不是“开源所以透明”就结束
Immich 的 GitHub Security Advisories 在 2026 年公开过多个不同等级问题，其中包括 Critical、High 和 Moderate。
这不等于“Immich不安全”。成熟项目公开漏洞并修复，本身是正常的软件生命周期。
真正应该得出的结论是：个人照片是高敏数据，所以升级与安全公告不是可选项。
尤其如果你的 Immich 暴露在公网，HTTPS、反向代理、账号密码、OAuth/OIDC、Session、API Key、共享链接、管理员权限、日志、访问来源都进入你的责任范围。
“我能在Docker里跑起来”不是安全验收。
七、还有一笔经常被漏掉的成本：硬件和时间
“开源免费”只是没有传统软件订阅费。
真实成本可能包括 NAS/小主机、硬盘、备份盘、异地存储、电费、域名、网络、UPS、更换坏盘、升级时间、排错时间。
如果你只是为了省每年几十美元云相册订阅，却花几十小时维护系统，纯经济上未必划算。
但如果你的目标是更大的本地库、数据控制、家庭共享、RAW/视频资产、避免某个生态锁死、可自定义工作流，那价值就不只是“省钱”。
八、谁适合自托管 Immich
比较适合：已经有NAS/服务器；愿意维护Docker和存储；照片量大；看重数据控制；有备份习惯；能接受升级责任。
不太适合：只想“一劳永逸”；没有第二份备份；不愿意看任何升级公告；把开放公网端口当成远程访问方案；家里所有照片只有这一个副本。
九、真正可以产品化的，不是“帮装Immich”
安装本身很快会被压价。
更有价值的是 Storage Plan、Migration Plan、3-2-1 Backup、Restore Test、HTTPS/Auth、Upgrade Policy、Security Advisory、Capacity Monitoring、Family Account Governance。
也就是说，卖的是：Self-hosted Media Readiness。
第一次收费做迁移与恢复演练，后续可以按年做安全/升级/容量维护。但要明确支持边界：你不可能承诺“永不丢数据”。
十、Stop Rule
如果你目前没有第二副本、没有恢复测试、不知道数据库备份在哪、服务器长期不升级、直接把管理界面暴露公网、出了问题没人能维护，那么先不要把手机原片全部删掉再“迁移成功”。
Immich 的价值是真的。
但 self-hosted 最危险的误区也是真的：
你获得的不是“免费的云”。你获得的是控制权，以及控制权后面那整套必须有人负责的工作。
十一、真正迁移照片前，我会先做一次“故障演习”
很多自托管教程最后一步是“手机开始自动上传”，但对真实家庭数据来说，那只是部署开始。
更有价值的验收是主动制造几个小故障：
场景1：误删
复制一小批测试照片，删除其中一部分，确认主库、回收机制和备份的行为是不是你以为的那样。场景2：数据库恢复
在不影响主库的测试环境里，用备份恢复一次数据库，确认人物、相册、元数据和文件关系没有断。场景3：服务器升级失败
先做 snapshot/backup，再模拟版本升级，确认出现兼容问题时有没有明确回滚路径。场景4：手机长期离线后重新同步
检查移动端的“已备份”状态与服务端实际文件是否一致，避免只相信界面状态。场景5：容量逼近上限
照片系统最容易在几年后才暴露容量问题。要提前定义80%、90%阈值、告警和扩容方案。如果一个家庭照片库从没经过任何恢复演习，那它仍处在“看起来有备份”的阶段。
十二、远程访问的风险应该单独算
很多人装完后下一步就是“怎么在外面访问”。
这一步会把系统从家庭局域网资产变成互联网暴露面。
需要分别考虑：
- 是否真的需要公网；
- TLS证书与域名；
- 反向代理配置；
- 管理员账号与普通账号分离；
- OAuth/OIDC是否配置正确；
- API Key最小权限和轮换；
- 分享链接是否有期限；
- 登录失败/异常来源有没有日志；
- 漏洞公告后多久必须升级。
“端口通了”只是连接成功，不是安全成功。
十三、Self-hosted 的经济账应该怎么做
把云订阅和 Immich 比较时，至少拆四类成本。
Fixed Cost
服务器/NAS、硬盘、UPS、初始迁移。Recurring Cost
电费、异地备份、域名、可能的云存储与网络。Maintenance Cost
升级、故障排查、坏盘更换、容量规划、漏洞响应。Failure Cost
真正丢失照片、恢复失败、停机、家人无法访问时的损失。只有把这四项放进去，才知道“省订阅费”是否真的对你成立。
对一个已经有NAS、会维护、照片量很大的用户，Immich的边际成本可能很合理；对一个只想省几十美元、但完全不想维护的人，托管云的价格里其实包含了他本来不愿承担的运维。
十四、V3怎么验证 Self-hosted Media Readiness
不要以“安装成功”作为成功指标。
真正的 V3 指标应该是：
- 30天后自动备份成功率；
- 随机抽10张照片能否从备份恢复；
- 一次升级的停机时间；
- 一次故障定位花多久；
- 家庭成员是否能独立使用；
- 管理者每月维护分钟数；
- 是否出现“主存储其实也是唯一备份”的错误决策。
如果这些数据出来以后，用户反而选择回到托管云，那也不是失败。
那是 V3 告诉你：控制权并不适合所有人。