第 3 章 · 容量与性能规划
适用对象：架构师、交付工程师 · 阅读约 12 分钟 · 对应产品界面版本 v1.2.0
容量规划要同时估算受保护数据量、日变化量、保留周期、重删压缩效果、并发作业和备份窗口。这一章给的是计算框架和取值区间，不是产品承载上限——源文档明确说明现有材料只支持建立框架，产品的官方上限尚未给出。
读完这一章你会做：
- 用四个参数而不是主机台数估容量
- 按公式算出单存储库的规划容量，并知道安全系数该取多少
- 用备份窗口反推最低有效吞吐，判断带宽够不够
- 按 50 / 200 / 500 三档选服务器配置，并知道三篇源文档在同一档上的取值差多少
- 判断单个数据获取器该带多少台主机、并发线程怎么设
先定这四个参数
只算主机台数会算错。同样 200 台，单机平均数据量从 200 GB 升到 2 TB，所需数据盘与备份窗口会显著放大；反之以增量为主并启用重删压缩，实际占用会明显下降。规划先落这四个：
| 参数 | 怎么取 |
|---|---|
| 有效数据总量 | 受保护数据的原始容量，逐台采集后求和 |
| 日变化量 | 同类业务实测，不能用单次任务的界面数值代替 |
| 保留周期 | 先定保留再定容量，保留策略、副本与归档会成倍放大占用 |
| 重删压缩比 | 必须来自同类业务实测。虚拟机整机镜像的重删率通常高于文件数据。源文档给的几组比率互相对不上，本手册不给推荐取值，见下文「重删与压缩的比率不要照抄」 |
存储容量怎么算
源文档给的估算公式是：
规划容量 = 原始容量 × (1 − 重删率) × 保留份数 × 安全系数
| 参数 | 取值 | 说明 |
|---|---|---|
| 原始容量 | 受保护数据总量 | 逐台采集 |
| 重删率 | 0–0.9（按业务实测） | 未启用重删时取 0 |
| 保留份数 | 折算为等价全量份数，1.5–3 倍 | 例如 1 份全备 + 30 份增量可折算为 1.5–3 份全量；GFS 长期保留会显著抬高 |
| 安全系数 | 1.2–1.5 | 覆盖元数据、临时空间、完整性校验和恢复时的额外占用 |
若另行启用压缩，可再乘以压缩率修正系数。
示例（源文档给的示例值，不是推荐取值）：原始容量 20 TB、重删率 0.5、折算保留 2 份全量、安全系数 1.3：
20 × (1 − 0.5) × 2 × 1.3 = 26 TB
重删与压缩的比率不要照抄
恢复篇记录的同一次增量备份里有两组数：
- 实测落盘：单次增量 7.21 GB，落盘后占用 827.74 MB，约为原始变化量的 11.5%（同一段又写作「备存率约 892%」）
- 单次记录的比率：重删率 22.97%、压缩率 65.84%，按
(1 − 22.97%) × (1 − 65.84%)推算落盘应为 26.3%
两者差一倍多。同一段接着又建议「保守取 0.2–0.3，不要直接按 0.115 规划」，等于给出第三个取值。本手册不在三者之间取舍，也不给推荐值。 规划时填你自己环境同类业务的实测值，并在方案里写明这个数的出处。
还有一处容易错一个数量级的地方：三篇源文档描述同一件事用了三种口径，换算前先确认手上的数属于哪一种。
| 口径 | 长什么样 | 出处 |
|---|---|---|
| 比例（1 − 重删率） | 重删率 0.5，落盘 50% | 容量篇的公式 |
| 系数（落盘占原始的比例） | 0.115，或建议值 0.2–0.3 | 恢复篇的实测与建议 |
| 倍数（原始 ÷ 落盘） | 892% | 恢复篇的「备存率」 |
把「系数 0.2–0.3」直接填进容量篇公式里「1 − 重删率」的位置，等于把重删率当成 0.7–0.8，和该篇示例用的 0.5、区间 0–0.9 的用法不是一回事。
架构篇把各项拆开相加：可用容量 ≈（原始数据量 × 全备份数 + 原始数据量 × 变化率 × 增量份数）÷ 重删压缩比 + 副本/归档副本容量 + 元数据与索引容量 + 重删库元数据容量，再乘 1.2–1.3 的增长与安全系数。
两处差异有两点：一是安全系数区间不同（1.2–1.5 与 1.2–1.3）；二是架构篇把副本归档、元数据索引、重删库元数据单列，容量篇把它们并进了安全系数。本手册不替你选一套。 做方案时明确写清用了哪一套、副本归档算在哪里，不要一半用一套。
重删库元数据是容易漏算的一项：源文档给的参考占比是受保护数据量的 1%–5%。
备份窗口与带宽
可用窗口、需传输数据量和协议开销共同决定最低有效吞吐。网络带宽还要保留业务余量，并通过限速与并发设置验证。
存储库的持续写入吞吐按下式取：
持续写入吞吐 ≥ 备份窗口内需写入数据量 ÷ 窗口时长 × 1.5
恢复侧的时间参考区间如下。这是用于窗口规划的取值区间，不是本产品的实测结果，也不是承诺值；实际耗时受网络带宽、存储介质、压缩去重、并发与文件数量影响，单个小文件与大目录的表现差异极大。
| 恢复类型 | 数据规模 | 取值区间 |
|---|---|---|
| 单文件（小于 1 GB） | 1 个文件 | 秒级至 1 分钟 |
| 目录（约 10 GB，数千文件） | 10 GB | 约 2 至 10 分钟 |
| 文件级 | 100 GB | 约 20 至 60 分钟 |
| 卷级 | 1 个卷（约 100 GB） | 约 20 至 60 分钟 |
| 整机（千兆网络） | 1 台主机（约 100 GB） | 约 30 至 120 分钟 |
可以拿来对表的实测锚点
下面三条取自同行业备份产品的运行日志，源文档明确标注非 SupDRC 实测：
| 场景 | 实测 | 有效吞吐 |
|---|---|---|
| 全量备份 | 780 GB，耗时约 207–208 分钟 | 约 64 MB/s |
| 增量备份 | 单次 6.6–9.2 GB，耗时 11–14 分钟 | 约 9–12 MB/s |
| 异机跨平台整机恢复（NBD 传输） | 118.7 GB，耗时 37 分 35 秒 | 约 54 MB/s，约合 430 Mbps |
这三条不是 SupDRC 的实测数据，不能写进 RTO 或备份窗口的承诺值。整机恢复场景还要单独记录目标主机的磁盘写入能力，避免把存储库的读带宽误判为主机瓶颈。
三档服务器配置
源文档按受保护数据总量划分环境规模，再按主机台数折算成三档。
50 台档（受保护数据总量不超过 40 TB）
按 50 台、单机有效数据 200 GB–800 GB、合计原始数据约 10–40 TB 折算。
| 资源项 | 推荐配置 | 备注 |
|---|---|---|
| CPU | 1 颗 × 16 核 | 最低不低于 16 核 |
| 内存 | 16–32 GB | 同节另注「最低 32 GB、推荐 64 GB」，见下方提示 |
| 系统盘 | 200–480 GB，SSD 优先 | 系统盘与数据盘分离 |
| 数据盘 | 企业级 7.2K HDD 3 块起组 RAID5，容量按上文公式预留 | 已作系统盘的磁盘不得复用 |
| 阵列卡 | 2 GB Cache（推荐）；无要求（最低） | — |
| 网络 | 千兆；管理流量与备份流量建议分离 | 大型档建议万兆 |
| 部署架构 | 单节点 | 多节点用于更大规模 |
同一节的表格写「内存 16–32 GB」，备注却写「最低 32 GB、推荐 64 GB」——表格的推荐值低于备注的最低值。本手册不替你选。 采购前按备注的下限（32 GB）报，并把这条差异写进方案的待确认项。
200 台档（受保护数据总量大于 40 TB 且不超过 100 TB）
按 200 台、单机有效数据 200 GB–500 GB、合计原始数据约 40–100 TB 折算。
| 资源项 | 推荐配置 | 备注 |
|---|---|---|
| CPU | 2 颗 × 16 核 | 并发作业越多，CPU 余量越重要 |
| 内存 | 32–64 GB | 开启重删或压缩时内存占用上升 |
| 系统盘 | 480 GB SSD × 2，组 RAID1 | 独立于数据盘 |
| 数据盘 | 企业级 7.2K HDD，RAID5 或 RAID6，按规划容量配置 | 单存储库上限见下文 |
| 阵列卡 | 2 GB Cache | 建议带电池或电容保护 |
| 网络 | 千兆 + 万兆，备份网优先万兆 | 与生产网隔离更佳 |
| 部署架构 | 单节点，或加 1 个存储 / 代理节点 | — |
500 台档（受保护数据总量大于 100 TB）
按 500 台、单机有效数据 200 GB–400 GB、合计原始数据 100 TB 以上折算。
| 资源项 | 推荐配置 | 备注 |
|---|---|---|
| CPU | 2 颗 × 16 核及以上（合计不少于 32 物理核） | 管理节点与代理节点分开计 |
| 内存 | 64–128 GB | 元数据库与并发任务共同占用 |
| 系统盘 | 480 GB SSD × 2，组 RAID1 | 建议预留日志与升级包空间 |
| 数据盘 / 存储 | 多存储库或分布式存储节点 | 避免单一 RAID 组过大 |
| 元数据 | 建议与数据盘分离，使用 SSD | 元数据随机 IO 影响检索与恢复 |
| 网络 | 万兆备份网；代理节点就近部署 | 跨网段需规划多网卡 |
| 部署架构 | 多节点（管理 + 多个代理 / 存储节点） | 需考虑管理节点高可用 |
三篇源文档在同一档上的取值不一致
同一个规模档，三篇源文档给的数不一样。下表原样并列，本手册不做取舍，请在方案评审时定一次口径并记录依据：
| 档位 | 项目 | 容量篇（本章依据） | 架构篇 | 兼容性篇 |
|---|---|---|---|---|
| 50 台 | CPU | 1 × 16 核（最低不低于 16 核） | 8–16 核 | 8–16 核 |
| 50 台 | 内存 | 16–32 GB | 32–64 GB | 32–64 GB |
| 50 台 | 系统盘 | 200–480 GB SSD | 200 GB SSD | 200 GB SSD |
| 50 台 | 网络 | 千兆 | 2 × 10GE | 千兆起步，建议万兆 |
| 200 台 | CPU | 2 × 16 核 | 16–32 核 | 16–32 核 |
| 200 台 | 内存 | 32–64 GB | 64–128 GB | 64–128 GB |
| 200 台 | 系统盘 | 480 GB SSD × 2 RAID1 | 2 × 200 GB SSD RAID1 | 200 GB SSD |
| 500 台 | CPU | 2 × 16 核及以上 | 32 核以上 | 32 核以上或多节点 |
| 500 台 | 内存 | 64–128 GB | 128–256 GB | 128–256 GB |
| 500 台 | 网络 | 万兆备份网 | 2 × 25GE 或绑定多链路 | 万兆或 25G |
50 台档的内存差一倍（16–32 GB 对 32–64 GB），200 台档同样差一倍，500 台档差一倍。按低的报，上线后可能不够；按高的报，投标可能不过。这不是可以自行折中的地方，要由产品方给一份口径。
单个数据获取器带多少台
| 项目 | 基准值 | 约束与说明 |
|---|---|---|
| 单 Proxy 承载被保护主机数 | 20–50 台 | 取决于单机数据量、日变化率与备份窗口 |
| 单 Proxy 并发流（传输线程） | 默认 3，区间 1–8 | 同一时间内运行任务的总线程数不能超过宿主机的逻辑核心数，超出部分不能提升速度 |
| 单 Proxy 并发作业数 | 4–8 个并发任务 | 与磁盘数量和限速策略联动 |
| 扫描线程 | 默认 3，应小于传输线程 | 扫描过度会挤占元数据 IO |
| 单机并发磁盘数 | 核查环境记录为 8 | 字段可取范围与填 0 的含义见下方 TODO |
承载数接近上限时的处置顺序：先降低并发流或加大限速，不要继续加主机；若备份窗口仍不足，再增加 Proxy 数量并重新分配主机，使各 Proxy 负载大致均衡。
兼容性篇另按管理端规模给了一组并发建议——小规模（50 台以内）并发备份 4 至 8、并发恢复 2 至 4；中规模（51 至 200 台）并发备份 8 至 16、并发恢复 4 至 8；大规模（201 至 500 台）并发备份 16 至 32、并发恢复 8 至 16；建议策略数分别为 50–150、150–500、500–1500。这组值的口径是「单管理端」，和上表的「单 Proxy」不是一个维度，源文档没有说明两者怎么换算。
管理平台与存储库基线
| 组件 | 资源项 | 取值 |
|---|---|---|
| 管理平台 | CPU | 8–16 核 |
| 管理平台 | 内存 | 16–32 GB |
| 管理平台 | 系统盘 | 200–480 GB，SSD 优先 |
| 管理平台 | 数据库 | 与系统盘同机时预留不少于 100 GB；元数据量大时独立 SSD |
| 存储库 / Proxy 节点 | CPU / 内存 | 16 核 / 16–64 GB |
| 存储库 / Proxy 节点 | 磁盘 | 企业级 7.2K HDD 组 RAID5 或 RAID6；元数据建议 SSD |
| 存储库 / Proxy 节点 | 网络 | 备份网不低于 1GbE，中大型 10GbE |
| 存储库 / Proxy 节点 | 持续写入吞吐 | 按上文公式推导 |
同一节的正文写「服务器最低配置为 CPU 16 核、内存 32 GB、系统盘 200 GB」，而表格里管理平台一行写的是 8–16 核 / 16–32 GB——表格值落在了正文声明的最低配置之下。两处都照录在这里，请按方案评审确定的口径执行。
合设还是分离：管理平台主要消耗 CPU 与数据库 IO，存储库主要消耗磁盘顺序写带宽和网络带宽。二者合设时取两组基线的较高值，并额外预留 20%–30% 余量，避免备份任务与管理操作互相争抢资源。
各组件的资源占用参考
下表是各组件在两个典型场景下的占用区间，用作规划起点。实际占用与并发作业数、压缩加密等级、重删库规模和数据变化率强相关。
| 组件 | 空载 CPU | 备份 / 恢复期 CPU | 内存 | 磁盘 / 缓存 | 网络 |
|---|---|---|---|---|---|
| 被保护主机 Agent | 低于 1 核 | 0.5–2 核 | 100–500 MB | 断点续传或缓存启用时占用本地磁盘 | 受任务限速约束 |
| 数据获取器（Proxy） | 低于 1 核 | 2–8 核 | 4–16 GB | 按并发磁盘数与缓存配置 | 接近链路带宽上限 |
| 数据存储库（Repository） | 1–2 核 | 2–8 核 | 8–32 GB | 重删库元数据约占受保护数据量的 1%–5% | 写入带宽为瓶颈 |
| 管理平台（含 Backup Server） | 1–2 核 | 4–16 核 | 16–64 GB | 系统盘 200 GB 起；元数据库随还原点数增长 | 管理与调度流量，带宽需求低 |
| 挂载服务器（Mount Server） | 低于 1 核 | 2–4 核 | 4–8 GB | 挂载缓存随还原点规模增长 | 恢复期带宽敏感 |
采集方法：在空载、全量备份、增量备份、恢复四个场景分别采集至少 15 分钟瞬时值与 60 分钟均值，同时记录 P95、并发作业数、压缩加密等级、重删库规模与平台版本。只有同一版本、同一并发数下的数据才能横向比较。
单存储库能放多大
| 参数 | 取值 |
|---|---|
| 单存储库参考上限 | 20–100 TB，超过后建议拆分多存储库或多节点 |
源文档写明「单存储库的官方容量上限未在产品技术资料中给出」。20–100 TB 只能用于选型沟通，不要当成产品承载能力写进承诺。上文示例算出的 26 TB 若按 100 TB 为参考上限，仍在单库范围内。
到顶了会怎样
规划阶段就要知道触达上限时长什么样，否则只能等任务失败才发现。
| 触达的上限 | 典型表现 | 首要处置 |
|---|---|---|
| 备份存储容量 | 任务转为失败或告警，写入被拒绝，存储水线告警 | 清理过期还原点并扩容存储 |
| 并发备份任务 | 新任务排队、超时或直接失败，备份窗口被拉长 | 降低并发并错峰，再评估节点扩容 |
| 并发恢复任务 | 恢复排队或失败，恢复窗口超出预期 | 限制并发恢复，优先恢复关键业务 |
| 管理端连接数与会话 | 页面与接口响应变慢或拒绝连接，自动采集中断 | 降低采集频率，核对会话超时设置 |
| 策略数与对象数 | 无法新建策略或保护对象 | 合并同类策略 |
| 单任务文件数 | 任务失败或部分文件被跳过 | 拆分任务，核对跳过日志 |
| 保留周期 | 触发自动清理，删除最早的还原点 | 调整保留策略，扩容后延长保留 |
| 许可授权范围 | 到达授权主机数或容量后无法新增保护对象 | 核对许可计量口径并补授权 |
| 备份窗口 | 任务在窗口内无法完成，与业务高峰重叠 | 错峰、改增量策略、提升带宽或节点扩容 |
前者需要扩容，后者只需调整参数或错峰。在定位原因前盲目扩容会掩盖真实问题。
扩容路径
| 路径 | 做法 | 影响 | 停机要求 |
|---|---|---|---|
| 原存储扩容 | 先扩底层卷或阵列，再扩文件系统，重新挂载并导入原有备份数据 | 目标存储无需重建，任务不必改目标 | 需停机窗口，扩容前先停止备份任务 |
| 新增存储 | 增加本地磁盘，或通过 NFS / CIFS / iSCSI / FC 挂载外部存储 | 需为任务重新指定目标存储，或新建任务时选择新存储 | 可在业务低峰在线添加 |
| 节点扩容 | 部署新节点加入平台，在存储设备处选择该节点 | 计算与存储同步扩展，提升并发与吞吐 | 低峰或停机窗口；需保证 IP 不冲突且与主节点互通 |
| 纵向扩容 | 增加 CPU 核数、内存、网卡与链路带宽 | 提升单机并发与吞吐，不改架构 | 需停机 |
| 参数与策略优化 | 错峰调度、限制并发、启用压缩与重删、按个数保留、拆分大任务 | 不新增硬件；优化过度会降低保留深度或延长单任务时间 | 无 |
扩容实施要求：扩容前完成一次容量与增长趋势评估并留存评估报告；扩容在变更单下执行，写明窗口、影响面、回退步骤与验证人；扩容后必须回归验证「新建备份、增量备份、文件级恢复、整机恢复」四项，确认扩容没有破坏既有还原点的可恢复性。
日常要盯的容量项
规模上线后纳入巡检（见第 11 章）：
- 备份存储剩余空间与水线
- 重删库清理时间是否与备份窗口冲突
- 任务日志中的重复警告与未处理错误
- 各任务执行时间是否已错开
这几项用于在触达上限之前发现趋势，而不是等任务失败才处置。
常见问题
只知道主机台数，能不能直接套档位？ 不能。同一档内实际可承载的规模还取决于单主机数据量、全备比例、备份窗口长度、网络带宽与重删压缩比。按四个参数估，不要只算台数。
重删率该填多少？ 本手册不给推荐取值。源文档里同一次增量备份的两组数对不上——实测落盘约 11.5%，按重删率 22.97% + 压缩率 65.84% 推算却是 26.3%，同段还另给了一个「保守取 0.2–0.3」的建议。填你自己环境同类业务的实测值，并写明出处。界面上单次任务显示的数值不能代替实测。
为什么同一档三篇文档给的内存不一样？ 源文档本身口径不一致，本手册原样并列没有取舍。报价前要由产品方给一份统一口径，见上文「三篇源文档在同一档上的取值不一致」。
传输线程是不是越多越快？ 不是。同一时间内运行任务的总线程数不能超过宿主机的逻辑核心数，超出部分不能提升速度；扫描线程还应小于传输线程。
单存储库到底能放多少？ 官方上限源文档没给。20–100 TB 是参考区间，用于判断要不要拆库，不能当承诺值。
存储扩容会不会影响已有的还原点？ 扩容后必须回归验证新建备份、增量备份、文件级恢复、整机恢复四项来确认。扩容对既有还原点影响的官方结论尚未取得。