Do not call an Immich backup finished until you have timed a restore.
A backup job only proves that files were written somewhere. A restore drill proves whether your Immich database, uploaded media, generated assets, paths, credentials and version choices can become a usable library again inside an acceptable recovery window.
RPO and RTO in plain terms
| Term | Meaning for Immich | Example assumption |
|---|---|---|
| RPO | How much recent library change you can afford to lose. | Daily database backup plus nightly media backup means up to about one day of new uploads may be at risk. |
| RTO | How long the library can be unavailable while you recover. | A 12TB restore at 2TB/day is a multi-day recovery, even if the backup exists. |
| Restore evidence | The proof that the plan worked. | Timestamped restore log, screenshot notes, file counts, sampled albums and a list of fixes. |
What the drill must prove
Immich states that a comprehensive backup includes both uploaded photos/videos and the database. Automatic database backups are stored under UPLOAD_LOCATION/backups, but they contain metadata only. Immich also identifies critical original asset folders under UPLOAD_LOCATION, including library, upload and profile. Generated thumbnails and encoded videos can be recreated, but doing that adds recovery time.
A restore drill should therefore prove four things: the database backup is present and compatible, the media files from the same period are present, the restored paths match the new instance, and Immich's integrity checks can see readable and writable storage folders.
Quarterly restore-drill sequence
- Pick the target restore point. Record the database backup filename, Immich version shown by the backup list, and the media snapshot or folder copy that should match it.
- Restore to a separate location. Do not restore over the live library during a routine drill. Use a spare disk, temporary directory, lab host or isolated VM.
- Stage the expected folders. For a fresh install restore, Immich expects previous instance data directories such as
backups,encoded-video,library,profile,thumbsanduploadto be moved into the newUPLOAD_LOCATION. - Use the safest restore path for the drill. Immich documents restore through Settings for existing installations and restore from onboarding for fresh installations. Use the web flow unless you are deliberately testing command-line recovery.
- Respect version warnings. Immich displays compatibility indicators for backup versions. A different-version restore may require migrations, so record whether the restore target matched the backup version.
- Check integrity before judging success. During onboarding restore, Immich shows integrity checks for storage folders. Review readability, writability and file counts before proceeding.
- Sample the recovered library. Check representative original photos, videos, albums, users, profile images, search/index jobs and any external library mounts.
- Record the clock time. Separate download/copy time, database restore time, application startup time, integrity check time and post-restore job catch-up time.
RTO worksheet
| Measurement | How to capture it | Planning use |
|---|---|---|
| Protected media size | Measure restored media folders, not the drive label. | Feeds restore-throughput and storage planning. |
| Restore throughput | TB restored divided by elapsed copy/download hours. | Use this value in the homepage calculator's restore throughput field. |
| Database restore time | Time from selecting/uploading backup to health check complete. | Usually smaller than media restore, but critical to prove. |
| Post-restore jobs | Time for thumbnail, transcoding, metadata and ML queues to settle. | Determines when the library feels normal, not just online. |
| Manual fixes | Permissions, paths, credentials, mount names and version changes. | Turn each fix into a checklist item before the next drill. |
Pass/fail criteria
- Pass: database backup restores, integrity checks are clean or explained, critical media is readable, sampled albums/users work, and measured restore time is inside the stated RTO.
- Conditional pass: the library returns, but generated media must be rebuilt or background jobs need time. Record this as part of real RTO, not as a footnote.
- Fail: missing database backup, missing media folders, unknown repository password, incompatible version with no tested path, unreadable folders, or restore time longer than the family's/business's tolerance.
Commercial and source note
This guide does not recommend a backup provider, cloud tier, NAS brand or paid recovery service. The commercial decision comes after you know protected size, RPO, RTO, restore throughput and whether egress or provider limits make the target recovery time realistic.
Use the calculator's restore throughput field to estimate full media recovery time →
没有计时恢复演练，就不要说 Immich 备份已经完成。
备份任务成功只说明文件被写到了某个地方。恢复演练要证明 Immich 数据库、上传媒体、生成资产、路径、凭据和版本选择能否在可接受的恢复窗口内重新变成可用图库。
用普通话解释 RPO 和 RTO
| 术语 | 对 Immich 的含义 | 示例假设 |
|---|---|---|
| RPO | 你最多能接受丢失多少最近的图库变化。 | 每日数据库备份加每晚媒体备份，意味着大约一天内的新上传可能有风险。 |
| RTO | 图库恢复期间最多可以不可用多久。 | 12TB 按 2TB/天恢复，就是多天恢复，不会因为备份存在就变快。 |
| 恢复证据 | 计划确实有效的证明。 | 带时间戳的恢复记录、截图备注、文件数量、抽样相册和修复清单。 |
演练必须证明什么
Immich 说明完整备份需要同时包含上传的照片/视频和数据库。自动数据库备份位于 UPLOAD_LOCATION/backups，但只包含元数据。Immich 也标明 UPLOAD_LOCATION 下的关键原始资产目录，包括 library、upload 和 profile。缩略图和转码视频可以重建，但这会增加恢复时间。
因此，恢复演练应证明四件事：数据库备份存在且版本兼容；同一时期的媒体文件存在；恢复后的路径与新实例匹配；Immich 的完整性检查能看到可读写的存储目录。
季度恢复演练流程
- 选择目标恢复点。记录数据库备份文件名、备份列表显示的 Immich 版本，以及应与之匹配的媒体快照或文件夹副本。
- 恢复到独立位置。日常演练不要覆盖生产图库。使用备用硬盘、临时目录、实验主机或隔离虚拟机。
- 准备预期目录。全新安装恢复时，Immich 需要把旧实例的数据目录，例如
backups、encoded-video、library、profile、thumbs和upload，移动到新的UPLOAD_LOCATION。 - 使用最安全的恢复路径。Immich 文档说明既有安装可通过 Settings 恢复，全新安装可通过 onboarding 恢复。除非你专门测试命令行恢复，否则优先使用网页流程。
- 尊重版本警告。Immich 会显示备份版本兼容性提示。不同版本恢复可能需要迁移，所以要记录恢复目标是否与备份版本一致。
- 先检查完整性，再判断成功。onboarding 恢复期间，Immich 会显示存储目录完整性检查。继续前检查可读性、可写性和文件数量。
- 抽样恢复后的图库。检查代表性的原始照片、视频、相册、用户、头像、搜索/索引任务以及外部图库挂载。
- 记录时钟时间。分别记录下载/复制时间、数据库恢复时间、应用启动时间、完整性检查时间和恢复后任务追赶时间。
RTO 工作表
| 测量项 | 如何记录 | 规划用途 |
|---|---|---|
| 受保护媒体大小 | 测量恢复后的媒体目录，而不是硬盘标称容量。 | 用于恢复吞吐量和存储规划。 |
| 恢复吞吐量 | 恢复 TB 数除以复制/下载耗时。 | 填入首页计算器的恢复吞吐量字段。 |
| 数据库恢复时间 | 从选择/上传备份到健康检查完成。 | 通常小于媒体恢复，但必须证明。 |
| 恢复后任务 | 缩略图、转码、元数据和 ML 队列稳定所需时间。 | 决定图库何时真正恢复正常，而不只是能打开。 |
| 手动修复 | 权限、路径、凭据、挂载名称和版本变化。 | 把每个修复项写进下次演练清单。 |
通过/失败标准
- 通过：数据库备份恢复，完整性检查干净或有解释，关键媒体可读，抽样相册/用户可用，测得恢复时间在既定 RTO 内。
- 有条件通过：图库恢复，但生成媒体需要重建，或后台任务还要追赶。应把这计入真实 RTO，而不是脚注。
- 失败：缺少数据库备份、缺少媒体目录、不知道仓库密码、版本不兼容且没有测试路径、目录不可读，或恢复时间超过家庭/业务可接受范围。
商业与来源说明
本文不推荐备份服务商、云层级、NAS 品牌或付费恢复服务。商业选择应在明确受保护容量、RPO、RTO、恢复吞吐量，以及出站流量或服务商限制是否能满足目标恢复时间之后再做。