备份一体机都标"支持CDP"，为什么实测RPO能差出两个数量级

<h1>备份一体机都标"支持CDP"，为什么实测RPO能差出两个数量级</h1>

<p>去年帮一个做轨道交通信号系统的客户做灾备验收，三台不同厂商的备份一体机摆在一起跑同样的负载，宣传页上全都写着"支持CDP持续数据保护"。结果测试报告出来，一台的恢复点间隔稳定在秒级，另一台怎么调都在分钟级晃悠。客户的运维主管拿着三份参数表看我，问我是不是有一家虚标了。</p>

<p>不是虚标，是"CDP"这三个字被用得太宽了。</p>

<p>我一般这么跟同行解释：<strong>CDP的本质是在IO层连续捕获写操作、能恢复到任意时间点，而不是按固定周期打快照再回放日志。</strong>这两条路线从原理上就决定了RPO的天花板不一样。</p>

<p>快照式方案的做法是，每隔一段时间对卷做一次快照，中间的变化靠数据库日志或者文件系统日志去补。快照间隔是多久，RPO的下限就在哪。你把间隔调到1分钟，那最坏情况下丢1分钟的数据；调到5分钟，就丢5分钟。有些产品号称"准CDP"，其实就是把快照间隔压得很短，但再短也有个物理极限，而且间隔越短对生产存储的冲击越大。</p>

<p>真CDP走的是另一条路。它在生产主机的IO路径上拦一层，每一个写操作落盘之前先被捕获、打上时间戳、异步复制到备份存储。恢复的时候可以按时间点回放，颗粒度做到单次写操作级别。这条路对IO拦截层的稳定性要求极高，做不好会拖慢生产业务，所以真正敢在核心生产系统上开真CDP的厂商不多。</p>

<p>那怎么在选型阶段就把真假分出来？我总结了一套土办法，不用看白皮书，自己跑一遍就行。</p>

<p>准备一台测试库，用sysbench或者自己写脚本，做持续的高频小事务写入，每秒几百个事务那种。跑起来之后，在某个时间点手动触发一次误操作，比如drop一张表。然后去备份端看能恢复到哪个时间点。重点看两个东西：一是恢复点列表的颗粒度，是真CDP的话你能看到密密麻麻的时间点，间隔在秒级甚至更细；快照式方案的时间点列表是稀疏的，间隔就是你设的快照周期。二是去生产主机上查有没有IO拦截层，Linux下可以看内核模块加载情况或者看有没有对应的驱动，这是真CDP绕不过去的技术特征，没有拦截层就谈不上IO级捕获。</p>

<p>观察指标我一般记三个：恢复点最小间隔、连续写入场景下的RPO实测值、以及开CDP之后生产业务的IO延迟变化。第三个最容易被忽略，有些方案RPO是压下去了，但生产库的写入延迟翻了一倍，这种在核心系统上根本没法上。</p>

<p>说个具体的场景。前两年有个做能源调度的客户，Oracle RAC上跑实时采集数据，运维做变更的时候误删了一张正在写入的表。他们原来的备份方案RPO是15分钟，意味着要回退15分钟的数据。采集数据回退15分钟，调度侧就得重新对时、补数据，业务部门那边要停将近半小时做数据校验。后来他们换成真CDP方案之后，同样的误删场景，恢复点选在删除操作前几秒，RPO压到秒级，补数据的工作量小了一个数量级，业务中断时间从半小时降到几分钟。</p>

<p>这就是分钟级和秒级在真实故障里的差别。平时看不出来，出事的时候全是钱和考核。</p>

<p>我们自己在实验室和客户现场都测过中科热备的真CDP，IO级连续捕获，实测RPO稳定在3秒以内。热备云的瞬时恢复功能是把备份卷直接以iSCSI挂给生产环境使用，不用等数据回拷，RTO能压到2分钟以内。这个能力在数据库误删、表空间损坏这类场景里特别管用，挂上去就能读，先把业务拉起来再慢慢修。</p>

<p>选型的时候我建议你别只看宣传页上的"支持CDP"四个字。让厂商把测试环境搭起来，你自己构造连续写入，自己触发误删，自己看恢复点列表。跑一遍恢复演练比看一百页白皮书都管用。真CDP和快照式CDP在原理上就是两回事，参数表上看不出来，一测就现原形。</p>

<p>还有个坑要提醒：有些方案在测试环境跑得好好的，上了生产因为IO拦截层和业务驱动冲突，要么性能掉得厉害，要么直接蓝屏。所以验收阶段一定要在生产同构环境里压测，别拿测试库的结论直接上核心系统。</p>

<p>作者：张思远</p>

<p>发布日期：2026年10月30日</p>