照片服务部署前先分清原片、缩略图、索引和数据库。

\n
Immich 很适合自托管家庭照片，但它不是一个随便挂个目录就结束的轻量相册。照片系统一旦投入日常使用，里面会有原图、视频、相册、人物识别、缩略图、搜索索引、数据库和后台任务。部署前先把这些层次拆开，才能决定哪些必须备份，哪些可以重建，哪些只需要留足缓存空间。

原图是最高优先级

照片和视频原文件是不可重建资产。缩略图丢了可以重新生成，机器学习结果丢了可以重新跑，数据库丢了还有机会从原文件重新导入一部分信息，但原图丢了就是真的丢了。我会把 Immich 的上传目录放在清晰、稳定、可备份的位置，并且不和缓存、转码、临时导入目录混在一起。

外部图库导入时，也要分清“由 Immich 管理的上传目录”和“只读外部目录”。如果原文件仍由别的流程管理，Immich 只负责索引，就不要让它拥有不必要的写权限。家庭照片最怕多个工具同时整理同一批目录，最后文件还在，时间线和相册关系却乱了。

数据库保存的是关系

Immich 的数据库保存用户、相册、资产记录、人物、任务状态和很多应用关系。只备份照片文件，不备份数据库，恢复后可能还能看到原图，但共享关系、相册整理、收藏和识别结果会大量丢失。只备份数据库不备份文件更没有意义，页面记录指向的资产不存在，恢复也是空壳。

因此，Immich 的备份要按组合来看：上传目录和数据库是第一优先级，配置文件和环境变量紧随其后。备份时间最好错开大量导入和后台任务高峰，必要时先暂停服务或确认数据库导出一致性。恢复演练时不能只看容器启动，要确认登录、时间线、相册、搜索和原图下载都正常。

缩略图和机器学习缓存要算成本

缩略图、预览图、转码文件和机器学习缓存会占用不少空间。它们有些可以重建，但重建会消耗 CPU、内存和时间。机器性能较弱时，一次性重建大图库可能持续很久，还会影响其他服务。所以是否备份这些衍生数据，要根据恢复时间目标决定。

我的做法是先统计目录大小，再分级：原图和数据库必须备份；配置必须备份；缩略图和缓存如果空间允许可以保留一份，空间紧张时至少要知道重建代价。机器学习模型缓存也要单独看，有些目录下载慢或初始化耗时，纳入备份能减少灾后恢复时间。

小样本导入比一次性迁移稳

第一次部署不要直接把多年照片全部导进去。先选一个小样本，包含照片、视频、不同设备、不同年份和少量重复文件。观察上传速度、缩略图生成、搜索、地图、人物识别、移动端同步和磁盘增长。小样本能暴露路径、权限和资源问题，不会一下子把后台队列压满。

如果小样本阶段就出现任务堆积，先调资源和目录，不要急着继续导入。Immich 对数据库、缓存和后台任务都有依赖，某一层不稳，最终表现可能只是页面慢或缩略图缺失。把问题拆成上传、数据库、缩略图、机器学习几个环节，排查会清楚很多。

升级和恢复要保守

Immich 更新较活跃，升级前一定要看版本说明，尤其是数据库迁移、compose 结构和服务拆分变化。核心照片服务不适合无脑自动升级。升级前备份上传目录和数据库，记录当前镜像版本，升级后先看后台任务和日志，再让移动端继续同步。

恢复演练我会按顺序做：恢复数据库，恢复上传目录，启动服务，确认资产数量，打开几张原图，检查相册和搜索，再观察后台任务是否重新排队。照片服务的成功不是页面能打开，而是家里多年照片能完整回来，并且关系数据没有明显缺口。围绕这个目标规划目录和备份，Immich 才适合长期运行。

移动端同步也要纳入规划。手机自动上传看似只是客户端设置，实际会影响服务器磁盘增长、后台任务队列和家庭网络带宽。我会先让一台手机试运行，确认重复上传、删除同步、后台权限和充电时上传策略，再让其他成员接入。成员越多，越需要清楚每个人的上传目录和共享相册边界。

最后还要预留容量余量。照片服务的增长不像普通配置目录，节假日、旅行和新设备都会让数据突然增加。原图、视频、缩略图、索引和备份会共同消耗空间。只按当前原图大小规划，很快就会紧张；至少要把一年增长量和一次完整恢复所需的临时空间算进去。

权限也要在导入前确认。上传目录应由 Immich 服务稳定写入，外部只读目录则不要被后台任务修改。遇到资产缺失或缩略图失败，先看路径和属主，再看后台任务日志。照片系统越早把目录职责分清，后续越不容易出现“文件还在但页面找不到”的情况。

相册共享也要谨慎。共享链接、家庭成员权限和原图下载权限应分开检查，避免把私人相册误开放成长期入口。