基础设施估算
完整和增量备份合计需要多少空间？
使用工具
源大小乘代数易漏增量，每天加全量又高估。要明确一代定义、全量与增量如何保留、周期何时观察。
每周全量、每日增量、两代全量
source: 100 GB
full interval: 168 hours
increment interval: 24 hours
retained full generations: 2
change per increment: 10%
compressed size: 100%
copies: 1
phase since latest full: 0 hours结果 260GB：两全量 200，旧链六增量 60，每增量 100×10%=10GB。全量时不另做增量，一周是一全六增，不是七增。
这里两代不是两个恢复点，而二全六增共八点。若产品世代指总恢复点数，不能直接抄入全量代数，应确认保留对象。
同两代在周期后段为 320GB
观察位置由全量后零改 144 小时，新链多六增，二全十二增共 320GB。相同保持设置容量随时点变，全量刚做完不是周期最大。
观察位置须为增量间隔倍数且在下次全量前，本例零至 144 每二十四小时。下全量开始新周期，不模拟临时文件或旧链删除前重叠，设备余量另估。
期间外全量可能是期间内增量所需
期间模式保 168 小时、观察 144。最新全量为零，最早目标 -24；恢复它需 -168 全量和后续链。模型保依赖，故二全十二增 320GB。
简单删七天前文件可能破坏恢复依赖。产品可用合并合成全量等不同方式，本工具只模型周期全量增量，不能当手动删文件指令。
10% 变化是每次增量假设
每增量为源量乘变化率，100GB×10%=每次 10GB，非源量复利增长。同位置可反复改，变化量不等一周净新增。
间隔二十四改十二不会自动 10% 改 5%，仍每次输入率。应测对应间隔或明示假设，频率提高既不保证总量不变也非必定等比增长。
压缩与份数用于全保留链
260GB 条件压后 50% 为 130GB，两份回 260GB。此栏百分比填 50，与日志倍率 0.5 不同。全量增量同压缩率，不推重删共享块收益。
已压缩源再乘同压缩会重复缩小。统一源量、变化量、压后比例所处阶段，产品区分逻辑物理时须确认取哪项。
容量足够仍需另查可恢复
模型假定定期成功且链完整，不检查缺失损坏、丢钥匙、失败或配置。估容量后应在实际系统做恢复试验并测恢复时间。
报告除总量还留全量数、增量数、观察位置、保留方式，把两代展开具体链，结果才可解释。
删除旧全量前先看增量依赖
仅因全量早于保留窗口就删除，可能让窗口内增量无法恢复。差量链需要基础全量，所以容量比每日量乘天数更大未必浪费。应区分保留的恢复点与重建这些点所需的全部文件。
同一保留设置在全量刚完成与下次全量之前的增量数不同。260GB 与 320GB 说明单一时点可能低估峰值。合成全量、去重和共享压缩块属于产品特定模型，应以实测修正假设，而非声称本链模型复现所有产品。
副本越多容量越大，但同一故障会同时损失的副本未必提供预期保护。计算不验证位置、权限隔离或恢复流程。容量、可恢复性、恢复时间和可用恢复点都需分别验证，容量估算不是备份设计完成。