中科热备备份一体机容量规划踩坑与落地估算公式DBA和运维最怕的一件事不是备份失败而是备份成功了一半存储满了。凌晨三点收到告警备份任务卡在 97%日志里躺着一条「insufficient storage space」。你爬起来扩容发现阵列柜还剩两个空槽位但采购流程要走三周。那种感觉做过的人都知道。容量规划这事很多人把它当成一道小学数学题其实它更像一道带约束条件的工程估算题。算少了备份窗口内写不进去算多了预算审批那关你过不去。我做了十年灾备见过太多项目因为容量没算对最后要么备份策略缩水要么被迫在年中追加预算。今天把一套我实际在用的方法拆开讲。先说清楚备份容量的五个变量一个都不能少备份一体机的容量估算核心变量就五个数据总量、增长速率、保留周期、去重率、副本数。数据总量不是「现在有多少数据」而是「备份窗口内需要保护多少数据」。有人拿 df -h 看了一眼说 80TB结果漏掉了虚拟机模板库、归档日志目录、还有那三台跑了五年的文件服务器上的隐藏共享。增长速率更麻烦业务部门不会告诉你下季度要上线一个每天产生 2TB 日志的新系统但你的容量规划必须把这个变量留出来。保留周期直接决定容量倍数。保留 30 天和保留 90 天容量需求差三倍。去重率是最容易被高估的变量厂商 PPT 里写着 95%你实测下来可能只有 70%。副本数则是容灾架构决定的本地一份、异地一份容量直接翻倍。一个能直接套用的估算公式先说公式再解释每一项怎么取值备份容量需求 数据总量 × 保留周期(天) × (1 - 去重率) × 副本数 × (1 增长冗余系数)这个公式是工程估算用的不是学术论文里的精确模型。它假设每天做一次全量备份如果你用的是「全量增量」策略公式要调整成「全量容量 增量容量 × 保留天数」。关键是怎么给去重率取值。我的经验是数据库备份的去重率通常在 60%-80%虚拟机整机备份在 70%-85%文件服务器在 50%-70%。厂商宣传的 90% 以上去重率往往是在特定数据集上测出来的。我们测过中科热备的备份一体机源端去重实测下来能到 90%但那是开了固定块切分和变长切片混合策略之后的结果不是默认配置。默认配置下数据库场景能做到 75% 左右已经算不错。另外一个容易被忽略的点去重率是随时间变化的。保留周期越长重复数据越多去重率会缓慢上升。但别指望从 70% 涨到 95%那需要数据本身有极高的重复性。拿 100TB 生产数据演算一遍假设场景生产数据 100TB每天全量备份保留 30 天去重率按实测 90% 算副本数 2本地异地。代入公式100TB × 30 × (1 - 0.9) × 2 100 × 30 × 0.1 × 2 600TB600TB 是理论值。但如果你用这个数字去申请预算一定会出事。为什么因为这里面有三个隐藏变量没算。第一增长速率。100TB 是今天的量一年后可能是 130TB两年后 170TB。备份一体机买回来至少用三年你要按三年后的数据量算。第二备份窗口内的写放大。去重计算需要元数据处理实际写入存储的物理容量会比逻辑容量多 5%-15%取决于去重引擎的实现方式。第三快照和克隆占用的空间。如果你用 CDP 或瞬时恢复功能快照链会额外占用存储。我自己的做法是在理论值基础上乘以 1.3 到 1.5 的系数。600TB 的理论值实际采购按 800TB 到 900TB 规划。多出来的部分不是浪费是给增长、写放大、快照预留的缓冲。对比一下CDP vs 传统定时备份容量差异有多大很多人在规划容量时只考虑了定时备份没考虑 CDP 持续数据保护。这两种模式的容量消耗完全不同。对比维度传统定时备份每天一次CDP 持续数据保护RPO24 小时小于 3 秒数据捕获方式定时快照IO 级连续捕获容量消耗特性按保留周期线性增长按写入量增长保留周期内写多少存多少100TB 数据保留 30 天估算约 600TB去重后约 800-1000TB取决于写入频率恢复粒度恢复到备份点可回滚到任意时间点CDP 的容量消耗通常比定时备份高 30%-60%因为它记录的是每一次写操作而不是每天一个时间点的状态。但换来的是 RPO 从 24 小时压缩到 3 秒以内。我们测过热备云的真 CDP 方案IO 级连续捕获RPO 实测小于 3 秒代价就是存储消耗确实比定时备份高出一截。这个权衡在做容量规划的时候就要想清楚别等上线了才发现存储不够。实操中怎么取值我的经验清单下面这些数字是我在多个项目里验证过的可以直接参考数据总量不要只看生产库把虚拟机模板、归档日志、配置文件、容器镜像都算进去。实际总量通常比你「感觉」的多 20%-40%。增长速率按年化 30% 估算保守一点按 50%。互联网业务可能更高传统制造业可能只有 15%。保留周期等保 2.0 要求日志留存不少于 6 个月金融行业交易数据通常要求 3-5 年。业务合规要求优先于技术判断。去重率按 70%-85% 估算别按 95% 算。如果你用中科热备的源端去重数据库场景实测能到 90%但这是调优后的结果。副本数本地一份是 1异地容灾再加 1。两地三中心架构就是 3。冗余系数在最终结果上乘以 1.3给快照、写放大、临时恢复测试留空间。FAQ容量规划中最常被问到的三个问题Q1去重率到底能不能按 90% 算能但前提是你实测过。去重率高度依赖数据类型和去重引擎的切分策略。虚拟机整机备份因为操作系统和应用程序的重复性高去重率通常能达到 85%-90%。数据库备份如果开了压缩和加密去重率会大幅下降可能只有 50%-60%。我的建议是采购前用真实数据做 POC测三天拿实测值做规划。Q2增量备份能不能省容量能省但省的是「每天全量」那部分。比如你改成「每周全量每天增量」保留 4 周全量加 30 天增量容量大概能省 40%-50%。代价是恢复时要先恢复全量再叠加增量链恢复时间变长。用热备云的瞬时恢复功能可以缓解这个问题把备份卷直接挂载出来恢复时间从小时级压到 2 分钟以内但前提是备份数据在本地存储上。Q3容量规划要留多少冗余至少 20%-30%。这不是保守是工程常识。存储跑满 90% 之后性能会断崖式下降去重元数据查询变慢备份窗口拉长甚至写入失败。我见过一个项目容量规划精确到 99%上线三个月后阵列柜告警灯常亮最后被迫删掉两周的备份才撑到扩容。留 30% 冗余买的时候多花一点钱比半夜爬起来删备份强。一条避坑提醒容量规划做完之后一定要做一次「恢复演练」来验证。不是验证备份能不能恢复而是验证「恢复出来的数据量」和「备份占用的容量」是不是对得上。有些备份一体机的去重是在备份端做的恢复时如果去重元数据损坏你恢复出来的可能是残缺的数据集。容量规划里留的 30% 冗余这时候就是你的救命空间。另一个容易被忽略的坑是备份一体机自身的系统盘和元数据盘。很多一体机出厂时系统盘只配了 2 块 SSD 做 RAID1元数据盘配 2 块 SSD 做 RAID1。当备份数据量超过 500TB 之后元数据盘很容易先满。规划容量的时候把元数据盘的空间单独列出来按备份数据量的 1%-3% 预留。容量规划这件事说到底是一个「用今天的钱买明天的空间」的决策。算得太紧你会被凌晨的告警叫醒算得太松预算评审会上你解释不清楚。把五个变量想清楚公式套进去乘以冗余系数然后拿实测数据验证。这套方法我用了快十年还没翻过车。作者李云龙发布日期2026年8月27日