2026 实测：5 美元小机用 Immich 自建 Google 相册替代品（避坑+备份）

延伸阅读

更多相关攻略推荐：一个页面看遍所有信息流：Glance 个人仪表盘自托管避坑指南、2026 实测：Paperless-ngx 在 VPS 上建私有文档、2026 VPS 选购决策树与白皮书：一张图看懂怎么买、【游戏服 02】游戏服务器 VPS 推荐 2026：Minecraf、如何给 VPS 厂商做"信用评估"：跑路、超售与售后风险排查手册。

为什么 2026 年是自建照片库的拐点

如果你也受够了 Google One 一年涨一次价、免费额度早被 Gmail 和 Drive 吃光，那 2026 年真的值得认真考虑把照片搬回自己手里。更扎心的是，Gemini 的相册记忆功能已经把"你的照片会被当成训练数据"这件事摆到了台面上——条款一直允许，只是以前没明说。

好消息是，替代方案今年终于成熟了。Immich 在 2026 年 7 月发布了 v3.0 大版本，GitHub 星标突破 10 万（年中已到 10.8 万左右），背后有 FUTO 全职团队在维护，更新节奏基本每月一个版本。v3 带来了工作流自动化、HLS 实时视频转码、无损编辑和完整性校验，把它从"极客玩具"推到了"能当日常主力"的临界点。

最关键的一点：它把所有照片的原始文件留在你自己的磁盘里，Google 不会扫描、不会拿去喂模型、也不会某天改个价逼你续费。配合 iOS / Android 客户端后台自动备份，体感和 Google 相册已经差不太多。

选机器：5 美元小机到底够不够跑

先把话说透——标题里那台"5 美元小机"如果只是 1 核 1G 的入门款，那是绝对跑不起来的，别浪费时间。Immich 真正吃资源的是机器学习容器，它会把 CLIP 和人脸识别模型整包加载进内存来建索引。官方文档现在写的是：内存最低 6 GB、推荐 8 GB，CPU 至少 2 核、推荐 4 核。4 GB 不是不能跑，但必须关掉机器学习，等于主动放弃智能搜索和人脸识别这两个最香的功能。

所以"便宜"的真正解法不是挑最便宜的套餐，而是挑便宜又高内存的套餐。像 Contabo 的 Cloud VPS 高内存线、RackNerd 的周年庆大内存机型（常见 12 GB RAM 才十几美元）、Virtono 在欧洲机房的高性价比大内存方案，都是这个场景的好选择。一句话：宁可少两颗核，也要把内存堆到 8 GB 起步。

还有两个 2026 年的新坑必须提前说：第一，v3 之后 amd64 架构的机器学习容器要求 CPU 支持 x86-64-v2 指令集，2012 年以前的古董至强会被直接拒之门外，下单前先确认 VPS 的 CPU 型号；第二，数据库强烈建议放在本地 SSD 上，千万别用网络共享盘当数据库位置，否则性能崩、还可能丢数据。

磁盘也要按"原图 + 缩略图 + 转码视频"来规划，Immich 生成缩略图和转码视频通常会让整个媒体库额外膨胀 10% 到 20%。举个实在的例子：你手机里 200 GB 的照片，落到 Immich 上大概要留 240 GB 左右才稳。PostgreSQL 本身只占 1 到 3 GB，反而不用太担心。如果你的 VPS 系统盘小，记得把 UPLOAD_LOCATION 挂到一块单独的大容量数据盘上，别让根分区被原图悄悄写满，否则服务会直接挂掉。

十分钟部署：用官方 Docker Compose 跑起来

Immich 官方给的就是一套 Docker Compose，四件套分别是 immich-server（网页与接口）、immich-machine-learning（人脸识别与语义搜索）、Valkey（队列缓存，以前叫 redis）和 PostgreSQL（v3 起改用 VectorChord 向量扩展）。别从老博客抄片段，一定要用当前版本自带的 compose 文件，因为文件结构每个大版本都会变。

操作步骤：

• 新建目录并进入：mkdir -p ~/immich && cd ~/immich
• 下载官方 docker-compose.yml 和 .env 示例文件（去 Immich GitHub 发布页拿对应版本的）
• 编辑 .env：设置 UPLOAD_LOCATION（照片落地目录）、DB_DATA_LOCATION（数据库目录）、TZ 时区和一串够强的 DB_PASSWORD
• 启动：docker compose up -d，首次会拉取约 5–6 GB 镜像，耐心等几分钟
• 浏览器打开 http://你的服务器IP:2283，第一次登录创建管理员账号，这个号就是管理员

避坑点：v3 起很多发行版把 docker-compose（带横杠）废弃了，必须用 docker compose（空格）这个插件命令，否则会报错或装不上。另外数据库目录务必放在 SSD 上，缩略图虽然占空间但相对没那么挑盘。

手机自动备份、人脸识别与 CLIP 语义搜索

部署完第一件事，是在手机上装 Immich 客户端，登录后打开"自动备份"。它会把相机胶卷在后台静默上传，支持 HEIC、RAW、Live Photo 和各种尺寸的视频。到这里，你已经有了 Google 相册最核心的能力。

接下来是让它在本地"长脑子"。人脸识别用的是 InsightFace，语义搜索用的是 OpenAI 的 CLIP 模型：它把每张照片编码成向量存进 PostgreSQL 的 VectorChord 扩展里，于是你直接搜"海边 2023 孩子"就能出结果，不用手动打标签。注意 v3 把用了两年的 pgvecto.rs 换成了 VectorChord，老用户要跑一次迁移，新装用户直接就是新架构，没这个烦恼。

真实体验：首次导入大图库时，索引会在后台跑上几小时甚至几天，这是正常的，不需要 GPU。如果你那台机器内存只有 4 GB，建议直接在 .env 里把机器学习相关任务关掉，先用纯备份+时间线，等以后换了高内存机器再补索引。人脸和语义搜索属于"锦上添花"，没它照片照常能看能存。

从 Google 相册迁移：Takeout 导入的坑

这一步是绝大多数教程一笔带过、却最让人崩溃的环节。在 takeout.google.com 申请导出时，只勾 Google 相册，归档大小选 50 GB 的 ZIP（减小被拆成碎片的几率），导出类型选"一次性归档"。记住：下载链接大约 7 天过期，且只能下 5 次，所以拿到后立刻转存到你的 VPS 上。

关键坑来了：Google Takeout 会把每张照片的日期、GPS、相册信息拆成独立的 .json 旁挂文件，一份 500 GB 的相册导出会变成几十万个小文件，顺序全乱。官方 Immich CLI 其实不擅长重组这些 JSON，它更适合"整文件夹原样上传"。真正干这活的是社区工具 immich-go，它会把照片和对应的 JSON 智能配对，尽量还原相册、描述和定位。

• 装好 immich-go 后，把解压后的 Takeout 目录整理到一个根目录，例如 /data/google_takeout
• 在你的 Immich 网页后台"API 密钥"里生成一把 key
• 执行：immich-go upload --server https://你的域名 --api-key 你的密钥 --recursive /data/google_takeout

导完务必去"最近上传"里抽查时间戳。Takeout 里有些老照片、老视频的 EXIF 是缺失或错的，会被 Immich 标成 2000-01-01 这种幽灵日期，发现后用手动或 exiftool 纠正一下，否则时间线就乱了。

备份：rclone + restic 的 3-2-1 实战

最重要的一句话：Immich 不是备份，它是照片管理工具。它停了、盘坏了、手滑删了，你的照片就没了。请严格按 3-2-1 来：3 份数据、2 种介质、1 份异地。Immich 自己的数据库备份只含元数据、不含原图，所以"数据库"和"原图"要分开保护，千万别以为自动 dump 一次就高枕无忧。

数据库用 pg_dumpall 导出最稳。为保证一致性，备份前可以先停掉 immich_server 容器，导完再起：

原图（UPLOAD_LOCATION 目录）用 restic 加密推到异地，比如 Backblaze B2，既便宜又省心；再用 rclone 同步一份到外接硬盘做本地冗余：

两个避坑点：第一，restic 备份时把 thumbs/ 和 encoded-video/ 目录排除掉，它们是能重新生成的缩略图和转码视频，备份纯属浪费空间；第二，备份脚本最好挂进 crontab 每天凌晨跑，并且重大版本升级前一定先手动备一份，因为 Immich 偶尔会有破坏性变更，莽撞 docker compose pull 可能让数据库起不来。

最后一句忠告：备份不等于能恢复。3-2-1 里最容易被忽略的一步是"演练还原"——至少每半年挑一个备份，在另一台机器上真的 pg_restore 一次、把原图同步回来、登录看照片是否齐全。很多人直到硬盘真坏了才发现备份脚本早就因为权限或凭证过期而静默失败了。顺便把 rclone 的远端配置和 restic 的密码单独存一份到密码管理器，别和服务器绑死，否则服务器一旦进不去，备份也跟着抓瞎。