Immich 数据库备份：自动转储计划与手动备份怎么配

自托管的第一铁律：没有备份的数据等于没有数据。Immich 对此的回应是内置了数据库自动备份——从 v1.120.0 起官方集成，不需要你再写 crontab。

自动备份：默认就在跑

装好即默认开启：每天凌晨 2:00 自动创建一次数据库转储，保留最近 14 份，转储文件存在 UPLOAD_LOCATION/backups 目录里。

调整入口在 Administration（管理）→ Settings（设置）→ Backup（备份）：改时间、改保留份数都在这里。对绝大多数家庭用户，默认值就是合理值——一天一备、两周滚动，足够覆盖绝大多数故障场景。

关键认知：数据库备份里只有元数据（照片路径、用户、相册、人脸、编辑记录……），不含任何照片视频本体。它必须和 原始文件备份 成对使用，这个坑下面还会反复出现。

手动触发一次备份

两种场景需要手动触发：大规模操作（导入几万张照片、跑全库任务）前，以及升级前嫌自动计划赶不上。

路径一：任务队列。Administration → Job Queues（任务队列）→ 右上角 Create job → 选择 Create Database Dump → 确认。转储出现在同一目录，占用保留名额。

路径二：让 版本升级 的习惯替你把关——每次升级前手动触发一次，形成肌肉记忆。

备份文件的形态与管理

• 文件格式是 .sql.gz（压缩的 SQL 转储），数据库规模 1–3GB 时单份转储通常更小；
• 随 任务队列 跑，不阻塞正常使用；
• 文件就在 UPLOAD_LOCATION/backups，可以顺手纳入你的文件级备份范围（这样数据库备份也有了异地副本）。

三道防线的完整图景

数据库备份只是保险绳的一段。完整的 3-2-1 备份策略 是：原始照片文件 + 数据库转储 + 两者各自的异地副本。官方文档反复强调：数据库必须备份——因为 Immich 不会扫描文件系统来重建元数据，数据库丢了，文件就成了一堆「没有名字、没有时间、没有人脸」的孤儿。

备份好之后呢

备份的价值在恢复时兑现。真到那天，操作路径见 恢复数据库——建议你现在就把那页读一遍，并做个演练：恢复不是高深技术，但第一次操作永远不该发生在事故现场。