第一次备份与历史版本，容量怎么留

先分清“新增资料”和“留下的旧版本”

一年增加 0.4 TB 新照片，不代表一年备份历史也只占 0.4 TB。新增原片、文档反复改写、文件被删后仍保留、去重方式和轮转策略，都会影响仓库占用。

容量规划至少拆成四项：最新资料、历史版本预算、软件/仓库开销、你选择的空间留白。不知道的项应写待测，不能一律当零。

案例一：算一笔明确给定假设的预算

假设当前重要资料为 1.5 TB，每年增长 0.4 TB，按三年规划：

1. 未来最新资料：1.5 + 0.4 × 3 = 2.7 TB。
2. 用户另外给历史版本留出 0.6 TB。这个数是本例给定的预算，不是从年增长量自动推导的。
3. 最新资料加历史：2.7 + 0.6 = 3.3 TB。
4. 若希望留白占目的地容量的 20%，则初步目标为 3.3 ÷ 0.8 = 4.125 TB，尚未计入仓库实际开销。

所以标称 4 TB 的目的地不能按这组假设判为够用。更大的目的地仍要核对真实可用空间、软件限制和后续实测占用。

案例二：没有历史占用统计时怎样起步

可以先为一个短周期做粗预算。例如目前最新资料为 1.5 TB，假设每天额外产生约 10 GB 需要保留的旧内容，连续保留 30 天。这里的 10 GB 专指最新状态之外仍需留下的数据，不把已经计入最新资料的新照片再算一次。

按不考虑共享与去重的粗模型，历史约为 10 × 30 = 300 GB，即 0.3 TB；初步空间为 (1.5 + 0.3) ÷ 0.8 = 2.25 TB，仓库开销另算。

实际软件可能按块共享、按整文件保存，删除与轮转的释放时机也可能不同。10 GB 若只是猜测，2.25 TB 就只能用于比较情景。先让任务运行一段完整的保留周期，观察最新资料量、仓库实际占用和轮转后的变化，再修正预算。

“30 个版本”为什么不等于“30 天”

一天成功运行多次，30 个版本可能只覆盖很短时间；几天没有运行，也不会自动产生缺失日期的快照。按天、周、月保留又可能只留下某些代表时间点，规则要查自己的软件。

例如希望找回十天前被错误覆盖的文档，应在实际版本列表中确认错误前的内容还在。设置里写“保留 30”，不能替代这一步。轮转与释放空间可能也是分开的过程，不能看到删掉一个版本就承诺立刻腾出同等大小。

首次备份按这个顺序完成

1. 确认范围。 选择重要资料，核查排除规则、视频、外部库和应用数据是否在范围内。
2. 确认目的地。 看实际剩余空间与连接条件，并确认以后怎样从它取回资料。
3. 先设恢复目标。 最多接受损失多久的新内容、需要多久以前的版本，再映射到软件支持的运行与保留策略。
4. 完成首次运行。 等待结束，查看失败、跳过和警告，记录实际成功日期；界面显示“任务已建立”不算这一步完成。
5. 查看版本与占用。 确认能浏览预期资料、能选择需要的时间点，记下仓库已用和可用空间。
6. 做样本恢复。 从备份复制普通文件到新目录并打开，具体方法见恢复演练。
7. 安排后续检查。 查看失败通知是否确实可用，外置盘未连接或云端访问失败时由谁处理。首次成功后仍应检查后续运行。

通用流程不规定统一按钮，也不要求自动删除旧备份。调整保留策略可能影响旧版本，真实变更前先确认所需恢复点仍可用。

频率要对照实际间隔

假设最后一次成功在周一晚上，周二、周三任务都失败，到周四才发现。这段时间新增资料的保护间隔已经超过一天，即使设置仍写着“每天”。

因此核查的是最近一次实际成功和中间缺口。观察周期内没有错误，也只说明这个周期的情况，不能承诺未来最大损失时间始终不变。

什么情况要停下来补资料

• 历史占用未知：先给出最新资料下界和预算区间，不宣布某块盘一定足够。
• 版本列表没有目标日期：确认任务是否执行、轮转规则和资料是否在当时已纳入。
• 备份只包含数据库：查原应用是否还要求原文件和其他状态；Immich 就明确区分数据库与照片/视频。
• 想靠删除旧版本应急：先确认需要的恢复点和软件释放空间的机制，不直接套用别人的清理命令。

这篇最终应帮你留下最新量、版本假设、目的地空间、最后成功时间和一个样本恢复结果。任一项未知，就保留未知，不用“备份完成”四个字代替这些证据。