两类容量账要分开算
快照与复制都不复制全量数据，但它们都会持续占用容量，而且增长方式不同。快照占用的是变化块：源卷上每被改写的块都会把旧值保留到快照空间，因此消耗速度取决于变化速率与保留时长。复制占用的是目标端的逻辑容量：目标端需要能够容纳源端全部已用数据，实际物理占用则取决于是否采用精简配置以及写入增长。把这两本账分开计算，再叠加保护机制自身的元数据与缓冲开销，才是可靠的容量规划。
基本信息
| 快照容量 | 变化速率乘以保留时长，另加元数据开销 |
|---|---|
| 复制容量 | 目标端需容纳源端全部已用容量 |
| 精简配置 | 目标端可按实际写入占用，但需设置上限告警 |
| 快照密度 | 快照越密，单位时间元数据与预留需求越高 |
| 增长因素 | 业务增长、保留政策调整、快照频率提高 |
| 主要风险 | 快照池写满导致快照失效甚至影响生产卷 |
典型使用场景
- 新建快照策略前，先计算快照池需要多大容量
- 容灾项目立项时估算目标端容量与后续扩容节奏
- 年度预算：按业务增长率推算容量增量与采购时机
- 快照频率调整：从每小时改为每十五分钟时重新估算
- 复制扩容：目标端接近上限前判断扩容窗口
- 告警阈值设置与容量响应流程的落地
容量构成与偏差
| 组成 | 计算方式 | 常见偏差 |
|---|---|---|
| 快照变化块 | 变化速率乘以保留时长 | 只按单次快照大小估算 |
| 快照元数据 | 与快照数量和数据量相关 | 完全忽略这部分开销 |
| 目标端副本 | 源端已用容量 | 按源端总容量而非已用量估算 |
| 复制缓冲 | 与链路中断时长相关 | 未预留缓冲空间 |
| 精简超配余量 | 实际写入与逻辑容量的差额 | 过度超配导致容量无预警耗尽 |
| 增长余量 | 通常按年度增长比例预留 | 按当前用量刚好配足 |
快照容量的关键变量是变化速率而不是数据总量。一个容量不大但持续高速写入的数据库卷，快照空间消耗可能远大于一个容量很大但基本只读的归档卷。因此按卷容量比例分配快照空间是常见但不可靠的做法，应按实测变化速率分配。
快照池写满是容易被忽视的容量风险。多数产品在快照池空间不足时会先让快照失效，部分产品在生产卷继续写入时可能出现性能下降甚至写入受限。必须为快照池设置独立于生产卷阈值的告警，并把告警点设在真实上限的较低比例，留出处置时间。
容量估算示例
容量估算示例
# 快照：源卷日变化量 200 GB，保留 7 天 -> 约 1400 GB，另加元数据开销
# 若快照频率从每天提高到每 15 分钟，变化块总量不变但元数据与快照数上升
# 复制：源端已用容量 20 TB -> 目标端至少按 20 TB 逻辑容量预留
# 增长余量：按年增长 20% 计，第二年目标端需 24 TB 以上
# 以上为估算口径，实际占用与限额以产品实现和官方容量规划文档为准