外观
Immich：自托管照片与视频库
一个体验接近商业相册服务的自托管方案：手机自动备份、按人物和地点分类、时间线浏览、多用户共享。
先考虑要不要装
fnOS 自带相册应用，已经覆盖了手机备份和基本管理。装 Immich 的理由通常是：想要更强的搜索与识别能力，或者希望相册数据完全按自己的方式组织。
代价是实打实的：它需要多个容器（应用、机器学习、数据库、Redis），内存占用明显，机器学习模型首次运行时会占用大量 CPU。低配置的低功耗平台上体验会比较吃力。
部署要点
Immich 由多个服务组成，且版本之间有依赖关系。必须使用官方提供的 docker-compose.yml 和 .env 文件，不要自己拼凑——这是官方明确的要求。
配置时重点关注：
UPLOAD_LOCATION：照片实际存放位置，指向你的存储空间，例如/vol1/photos/immich。- 数据库目录：单独持久化，放在固态盘上性能更好。
- 需要硬件加速转码时，按官方文档额外引入对应的配置片段并映射
/dev/dri。
数据与备份
要分清两类数据：
| 内容 | 位置 | 重要性 |
|---|---|---|
| 原始照片和视频 | UPLOAD_LOCATION | 不可再生，必须严格备份 |
| 数据库 | 数据库容器的数据目录 | 丢了可以重新扫描，但相册、人脸标注等会丢失 |
| 机器学习缓存 | 缓存目录 | 可以丢弃，会自动重建 |
数据库要用导出工具备份，不能直接复制文件，见 PostgreSQL。
升级前一定先看版本说明
Immich 迭代很快，历史上有过需要手动操作的破坏性变更。每次升级前备份数据库，并读一遍对应版本的发布说明。 不要配置成自动更新。
已知坑
- 首次导入大量照片时，机器学习任务会让 NAS 持续满载数小时甚至数天。建议分批导入。
- 手机 App 的后台上传受系统电池优化影响，见照片备份排查。
- 同时运行自带相册和 Immich 会导致照片重复占用空间，决定用哪个之后就别两边都开自动备份。