前言
照片记录着生活中的点点滴滴。过去十几年里，我一直习惯使用 Google Photos 作为主要的照片存储和管理平台。
Google Photos 刚推出时，可以说是最好的照片管理工具之一。不限量存储、强大的搜索能力、优秀的人脸识别和时间轴管理，让我几乎把所有照片都上传到了 Google Photos。
然而随着 Google 取消免费无限容量政策，照片存储逐渐变成了一项持续支出。随着照片和视频数量不断增加，每个月都需要为额外空间支付费用。同时，由于网络环境原因，Google Photos 的访问体验也越来越不方便。
更大的问题在于，随着设备的增加，我的照片开始散落在多个平台。
- Google Photos：主要照片库
- iCloud Photos：部分 iPhone 照片
- 华为手机本地照片
- DJI 无人机照片和视频
- 运动相机视频
- NAS 本地存储
由于不同设备和平台之间的同步机制不同，同一张照片经常会出现在多个地方。
结果就是：
照片越来越多，但真正想找到一张照片却越来越困难。
因此，我决定借助 Immich 构建一个统一的照片管理中心，实现所有照片的集中管理和自动去重。
为什么选择 Immich
在选择照片管理平台时，我对比过多个方案：
- Synology Photos
- PhotoPrism
- Nextcloud Photos
- Immich
最终选择 Immich，原因主要有三个。
第一，体验最接近 Google Photos
Immich 提供了：
- 时间轴浏览
- 地图浏览
- 人脸识别
- 智能搜索
- 手机自动备份
- 多用户管理
对于 NAS 用户来说，已经具备替代 Google Photos 的能力。
第二，完全掌握数据
所有照片存储在自己的 NAS 中。
不再依赖第三方平台，也不再担心未来政策变化导致额外费用增加。
第三，强大的排重能力
这也是我此次迁移最看重的一点。
我的照片来源复杂：
- Google Photos
- iCloud
- 华为手机
- DJI 设备
- 本地目录
这些来源之间存在大量重复照片。
Immich 本身具备较好的重复照片识别能力，而 immich-go 工具又进一步增强了导入过程中的排重能力。
这意味着：
无论照片来自哪里，最终在 Immich 中都只保留一份。
这正是我想要的结果。
第一步：升级 Immich
开始迁移之前，我首先对 Immich 进行了升级。
我的版本已经比较老：
v1.135.3升级目标版本：
v2.7.5由于跨越多个大版本，因此先进行了完整备份：
- PostgreSQL 数据库
- Immich Library
- docker-compose 配置
- .env 配置
确认备份完成后执行升级。
升级完成后重新索引数据库和媒体文件，为后续的大规模导入做好准备。
第二步：导入 Google Photos
Google Photos 是我的核心照片库。
经过多年积累，导出的 Google Takeout 数据达到数百 GB。
Google Takeout 导出
通过 Google Takeout 导出 Google Photos：
Google Takeout
↓
Google Photos
↓
ZIP格式
↓
10GB分卷最终生成了数十个压缩包。
批量下载问题
由于文件数量巨大，手工逐个下载非常麻烦。
因此采用浏览器 Cookie 认证的方式编写自动下载脚本。
脚本实现：
自动读取Cookie
↓
自动下载压缩包
↓
失败自动重试
↓
断点续传最终实现无人值守下载。
使用 immich-go 导入
Google Photos 最大的问题是元数据。
很多拍摄时间、相册信息并不在照片文件本身，而是在对应的 JSON 文件中。
因此不能简单解压后直接上传。
最终采用：
immich-go upload from-google-photos进行导入。
导入过程中：
- 自动恢复拍摄时间
- 自动恢复相册
- 自动关联元数据
- 自动检测重复照片
整个过程虽然耗时较长，但最终成功保留了 Google Photos 的完整历史记录。
第三步：导入 iCloud Photos
相比 Google Photos，iCloud 的导出过程反而更加折腾。
Apple 数据导出
Apple 提供数据导出功能。
申请后会生成下载链接。
但这里有一个问题：
下载链接有效时间非常短实际测试大约十几分钟后就会失效。
暴力并发下载
面对这个限制，我采用了最直接的方法：
获取所有下载链接
↓
同时启动全部下载任务
↓
最大化利用有效时间虽然简单粗暴，但效果很好。
最终成功获取全部照片和视频。
使用 immich-go 导入
导入方式与普通目录类似：
immich-go upload导入过程中：
- 自动读取 EXIF
- 自动识别拍摄时间
- 自动排重
大量已经存在于 Google Photos 中的照片被自动识别为重复资产。
因此最终并没有出现照片数量翻倍的问题。
第四步：导入 DJI、运动相机和无人机素材
除了手机照片之外，我还有大量设备产生的视频文件。
包括：
- DJI 无人机
- DJI Action
- GoPro
- 运动相机
- 其他摄影设备
这些文件大多数以目录形式保存在 NAS 中。
例如：
DJI
├── 2023
├── 2024
└── 2025
Action
├── 骑行
├── 旅游
└── 日常这部分数据没有复杂元数据，因此处理相对简单。
直接通过 immich-go 导入即可：
immich-go upload /path/to/media工具会自动递归扫描所有目录。
同时保留：
- 视频拍摄时间
- 文件元数据
- 目录结构信息
immich-go：整个迁移过程的核心工具
整个迁移过程中，真正发挥关键作用的是 immich-go。
虽然数据来源完全不同：
- Google Photos
- iCloud Photos
- 本地目录
- DJI 视频
但最终都可以通过调整参数的方式完成导入。
例如：
Google Photos
→ from-google-photos
iCloud
→ 普通目录导入
本地媒体库
→ upload统一导入到 Immich。
这大大降低了迁移复杂度。
最终效果
经过数天整理和导入后，我最终完成了照片库整合。
数据来源：
Google Photos
+
iCloud Photos
+
华为手机照片
+
DJI照片视频
+
运动相机素材统一汇聚到：
Immich借助 Immich 的排重机制：
- 重复照片自动识别
- 重复视频自动过滤
- 仅保留唯一副本
最终形成了一套统一、干净、可持续维护的照片库。
Immich 的遗憾：DS218+ 已经有些力不从心
虽然整个迁移过程最终顺利完成，但在实际使用过程中，我也发现了一个新的问题：
Immich 越来越强大，而我的 DS218+ 已经有些跟不上了。
我的 NAS 是群晖 DS218+，这是一台非常经典的机型。
配置为：
Intel Celeron J3355
2核心
最大6GB内存在运行 Synology Photos 的时代，这样的配置基本没有压力。
但 Immich 近年来发展非常迅速，尤其是引入了：
- 人脸识别
- 智能搜索
- CLIP 向量检索
- 视频缩略图生成
- 地图索引
- 机器学习模型
这些能力背后都需要大量 CPU 和内存资源。
在导入数万张照片和数百 GB 视频的过程中，我明显感觉到 DS218+ 已经接近极限。
经常可以看到：
immich-machine-learning
ffmpeg
缩略图生成任务长期占用较高 CPU。
有时候即使暂停任务队列，后台仍然需要较长时间完成已经提交的索引任务。
特别是在：
- 人脸重新识别
- 视频转码
- 大规模导入
- 机器学习模型更新
这些场景下，DS218+ 的响应速度明显下降。
甚至会影响 NAS 上其它应用的正常运行。
对于照片浏览来说问题并不大，但如果希望充分发挥 Immich 最新版本的全部能力，那么硬件已经开始成为瓶颈。
下一步计划
目前 Immich 已经成为我的唯一照片管理平台，因此后续的重点不再是迁移，而是基础设施升级。
未来计划将 NAS 升级到性能更强的平台，例如：
- DS923+
- DS1522+
- 自组装 NAS
- Mini PC + Docker + Immich
让 Immich 的 AI 能力得到充分释放。
对于目前的 DS218+，我认为仍然能够胜任：
照片存储
日常浏览
手机自动备份但如果照片数量达到数万张以上，并且开启全部 AI 功能，那么升级硬件已经只是时间问题。
后记
回过头来看，这次迁移最大的收获并不是节省了 Google Photos 的订阅费用，也不仅仅是将照片从多个平台汇聚到一个系统。
更重要的是，我终于拥有了一套完全属于自己的照片管理体系。
从 Google Photos 的免费时代开始，到后来订阅扩容，再到今天完成向 Immich 的迁移，照片存储经历了从“依赖云服务”到“掌控数据”的转变。
如今，Google Photos、iCloud、华为手机、DJI 无人机以及各种运动相机产生的照片和视频，都已经统一汇聚到 Immich 中，并通过自动排重实现唯一存储。
未来即使更换设备、更换云服务，甚至更换 NAS，照片库本身都不会受到影响。
而对于一个已经积累了十几年照片和视频的人来说，这种确定性和掌控感，或许比任何功能都更加重要。
