用 Docker 部署 Immich，把手机相册从云上搬回自己家

如果你正在为两件事烦：手机相册每年扩容要交钱、以及不确定自己的照片被拿去做了什么——那 Immich 是目前最接近「自建谷歌相册」的方案。它有人脸识别、地图视图、时间轴、共享相册、iOS/Android 自动备份，界面和体验已经接近成品，而不是一个需要自己拼装的开源零件。

但这篇文章不打算只给你一段复制粘贴的配置。大多数人部署 Immich 失败，不是因为命令打错，而是因为在开始之前没想清楚存储怎么放。所以下面按真实顺序来。

一、先确认三件事

硬件。 Immich 比一般的自托管服务吃资源。官方建议 4 核 CPU + 6GB 内存起步，实测在 N100/N305 这类迷你主机上 8GB 内存跑得很稳；2GB 内存的轻量云服务器会直接在机器学习那一步被打满。如果你照片超过 5 万张，建议 8GB 内存起步。

存储规划。 这是最容易出事的地方。Immich 的照片按「上传时间」分目录存，一旦开始用，不能改上传目录结构，也不能事后换路径——数据库里存的是相对路径，挪目录会导致整个库失效。所以在跑第一条命令之前，先把目标目录定下来，比如 /srv/immich/photos，然后不要动它。

备份策略。 先说结论：只备份照片目录是不够的。Immich 的相册、人脸、收藏、共享关系全在 PostgreSQL 里。只恢复照片，你会得到一堆没有相册、没有人脸、没有顺序的原始文件。正确做法是照片目录和数据库转储一起备份。这一点后面单独讲。

二、目录结构

先把目录建出来，把权限理顺。用普通用户跑，不要用 root：

sudo mkdir -p /srv/immich/{photos,db,model-cache}
sudo chown -R $USER:$USER /srv/immich

三个目录的分工：

photos —— 你的原始照片和缩略图，这是命根子
db —— PostgreSQL 数据文件。注意这个目录不能直接当备份用，原因见第六节
model-cache —— 人脸识别和智能搜索的模型缓存，删了会重新下载，不影响数据

三、docker-compose 配置

Immich 更新很快，数据库和缓存镜像的版本必须和主程序匹配，所以不要照抄网上的固定版本号。正确做法是去 GitHub 的 releases 页面下载对应版本的 docker-compose.yml 和 .env，然后只改这几处：

services:
  immich-server:
    volumes:
      - /srv/immich/photos:/data          # 改成你的路径
    environment:
      TZ: Asia/Shanghai
    ports:
      - "2283:2283"
    restart: unless-stopped

  immich-machine-learning:
    volumes:
      - /srv/immich/model-cache:/cache    # 模型缓存持久化，避免重启重下
    restart: unless-stopped

  database:
    volumes:
      - /srv/immich/db:/var/lib/postgresql/data
    environment:
      POSTGRES_PASSWORD: 换成一个真的密码
      POSTGRES_DB: immich
    restart: unless-stopped

.env 里改两个值就够：UPLOAD_LOCATION=/srv/immich/photos、DB_PASSWORD= 和你上面填的一致。

restart: unless-stopped 是必须的——服务器重启后服务要能自己起来，而不是等你上去手动 docker compose up。

启动：

docker compose up -d
docker compose logs -f immich-server

看到 Immich Server is listening 就可以访问 http://你的IP:2283。

四、国内网络的两个实际问题

镜像拉不下来。 这是国内部署最常见的卡点。给 Docker 配加速器，在 /etc/docker/daemon.json 里加：

{
  "registry-mirrors": ["https://你的加速器地址"]
}

然后 sudo systemctl restart docker。加速器地址各家云厂商控制台都能拿到，个人也可以自建。

机器学习模型下载失败。 首次启动时 Immich 会去 HuggingFace 下模型（人脸识别、CLIP 搜索）。国内经常超时。解决方式是给这个容器配代理：

  immich-machine-learning:
    environment:
      HF_ENDPOINT: https://hf-mirror.com

这个环境变量对大多数 HuggingFace 客户端都生效。如果还是失败，检查容器内能不能访问外网。

五、手机自动备份的两个坑

Immich 的手机 App 体验不错，但有两个地方几乎所有人都会踩：

iOS 后台限制。 iOS 不会让 App 在后台长时间跑。所以「自动备份」实际是「App 在前台或系统给了后台额度时才备份」。照片多的时候，第一次全量备份必须把 App 开着、手机充电、连 WiFi、别锁屏，否则会断断续续拖好几天。备份完成后，日常增量就很快了。

Android 的省电策略。 国产 ROM（MIUI/HyperOS、ColorOS、OriginOS）会把后台同步杀掉。需要手动给 Immich App 开「允许后台运行」「忽略电池优化」，否则你会发现备份总是停在几天前。

外网访问。 你在外面也想备份，就得让 Immich 能从公网访问。三种做法，按推荐程度：

VPN 回家（Tailscale / WireGuard）—— 最安全，不用暴露端口，手机装个客户端就行。缺点是家里设备得保持在线。
反向代理 + 域名 + HTTPS —— 体验最好，但要注意：国内云服务器不备案不能用 80/443，家庭宽带通常也封了 80/443 入站，得用非标端口。
Cloudflare Tunnel —— 不用开端口，但要接受流量绕行海外的延迟，大文件上传会慢。

如果你只是自己用，强烈建议第一种。

六、备份：这是全文最重要的一节

Immich 的正确备份方式是两份：

# 1. 数据库转储（每天跑，很小，几百 MB）
docker exec -t immich_postgres pg_dumpall --clean --if-exists --username=postgres \
  > /srv/backup/immich-db-$(date +%F).sql

# 2. 照片目录（用 rsync 增量，别用 cp -r）
rsync -a --delete /srv/immich/photos/ /mnt/backup/immich-photos/

为什么不能直接备份 db 目录？因为 PostgreSQL 的数据文件在运行时是不一致的，直接拷可能在恢复时报损坏。pg_dumpall 是逻辑导出，恢复时不会有这个问题。

恢复的顺序也很重要：先恢复照片目录，再导入数据库，最后启动服务。反过来会出现缩略图丢失和相册错乱。

再补一条：照片这种数据请遵守 3-2-1 原则——3 份副本、2 种介质、1 份异地。最省事的做法是再来一台设备（或者一块移动硬盘放在父母家），用 Syncthing 单向同步照片目录过去。

七、常见故障对照

现象	原因	处理
上传后照片是空白/裂图	照片目录权限不对	确认容器内 uid 能读写 `/data`
人脸识别列表是空的	模型没下下来	查 machine-learning 容器日志，配 HF 镜像
搜索「狗」搜不到照片	智能搜索模型未加载完	首次索引要跑几小时，看任务队列
时间轴日期全乱	上传时没读 EXIF	检查原始文件是否被其他工具改过
磁盘满了但照片不多	缩略图占一半空间	正常现象，预留 1.5 倍原始照片的空间
升级后打不开	数据库迁移失败	回滚镜像版本，从备份恢复数据库

不要开 Watchtower 自动升级。 Immich 每个版本都可能带数据库迁移，自动升级一旦中途失败，你的库可能处于不可恢复的中间状态。正确做法是：升级前手动跑一次数据库转储，再改版本号。

八、什么时候不该用 Immich

Immich 不是万能的，三种情况建议换方案：

你只有 2GB 内存的机器 —— 用 PhotoPrism 或者干脆用 Nextcloud 的照片模块，资源需求低一个量级。
你只是想同步文件，不需要相册功能 —— 用 Syncthing，零维护成本，不需要数据库。
你的照片超过 30 万张 —— Immich 能扛，但索引重建会非常慢，建议提前做好性能规划，或者接受只对最近几年开启智能搜索。

九、一句话总结

Immich 值得装，但装之前定好存储路径，装之后做好数据库备份——这两件事决定了你以后是「用得很舒服」还是「某天照片全没了」。剩下的都是配置细节。

如果你还没准备好直接上 Immich，可以先从本页「影音与相册」栏目里挑一个轻量的试试，比如 PhotoPrism 或者 Ente，先跑通 Docker 和反向代理这套流程。