把云灾备理解成「开个云账号，把备份传上去」，是我这两年见过最普遍的认知偏差。去年帮一个省级政务云做灾备复盘，他们的运维负

<p>把云灾备理解成「开个云账号，把备份传上去」，是我这两年见过最普遍的认知偏差。去年帮一个省级政务云做灾备复盘，他们的运维负责人一直觉得自己「已经做了异地容灾」，直到做恢复演练才发现，核心库全量拉回来要十几个小时，带宽跑满也追不上增量产生的速度。云账号是买了，数据主权却悬在半空。</p>

<p>这个案例后来我复盘过很多次，问题出在最开始的需求定义上。他们采购时只问了云厂商三个问题：存储多少钱一 GB、SLA 几个九、能不能异地。厂商当然都说能。但没人问第四个问题：真出事的时候，我多久能把业务拉起来？这个问题的答案不在合同里，在物理链路里。</p>

<p>云灾备的本质是 BaaS 或 DRaaS，把备份存储和容灾编排托管在云侧。它解决的是成本形态和异地可达性，不是恢复速度。恢复速度这件事，物理定律说了算：你的专线带宽决定了单位时间能搬回多少数据，跟云厂商的 SLA 关系不大。举个具体的数：一条 1Gbps 专线，理论峰值 125MB/s，实际跑到七成就算不错，按 90MB/s 算，一天满打满算能回传 7.7TB。如果你的核心数据集是 50TB，光全量回传就要六天半，这还没算解压、校验和写入的时间。而业务不可能等你六天。</p>

<p>所以选型不能只问「上不上云」，得先算四笔账。</p>

<p><strong>数据量和增量速率</strong>决定带宽账和初始同步方式。我的经验阈值是：全量数据 10TB 以内、日增量不到 5%，云侧归档完全够用，一次种子盘寄送加增量同步就能收敛。种子盘这一步很多人省掉，直接走网络传全量，结果初始同步窗口拖到一周以上，增量还在不断产生，永远追不上。一旦全量过了几十 TB、日增量上到 10% 以上，专线成本会迅速吃掉云备份省下的那点钱。我算过一笔账：50TB 全量、日增 10% 的场景，要保证 24 小时内完成增量同步，至少需要 500Mbps 以上的专线带宽，一年专线费用在十几万到几十万不等，而同样数据的本地容灾一体机，三年总拥有成本可能只有这个数的一半。而且初始同步窗口可能拖到一周以上。这种规模我一般建议本地做一级保护，云只承接归档层。</p>

<p><strong>RPO 和 RTO</strong> 决定技术路线。这两个指标经常被混为一谈，其实差得很远。RPO 管的是「最多丢多少数据」，RTO 管的是「多久能恢复业务」。RPO 要求 24 小时，定时备份就行；压到 15 分钟以内，得上 CDP 或数据库复制；要求接近零，那才轮到双活。RTO 同理，小时级和分钟级是两种预算量级。我们测过中科热备的真 CDP，IO 级连续捕获，RPO 压在 3 秒以内，瞬时恢复把备份卷直接以 iSCSI 挂给生产环境，RTO 控制在 2 分钟。这个量级云侧很难做到，回传带宽就是天花板。热备云这套一体机和纯软双模式的部署形态，在工控场景里省了不少适配麻烦——工控环境往往有老旧的 SCADA 系统和专用协议，纯软部署能直接嵌进去，不用额外加硬件。</p>

<p>再补一个常被忽略的细节：RTO 里有一大块时间花在「决策」上。真出故障了，谁来判断要不要切换、切到哪个环境、切换脚本谁执行，这些流程如果没提前演练过，光沟通就能耗掉半小时。技术上的 2 分钟 RTO，加上组织流程，实际可能是 20 分钟。这部分云厂商帮不了你，得靠自己把 runbook 写清楚、定期演练。</p>

<p><strong>数据主权和合规约束</strong>是关基行业的硬门槛。等保 2.0 对异地灾备距离有明确要求，两地三中心的架构里，同城和异地各有分工。政务、电力、轨交这类场景，数据出不出自己的机房，往往不是技术选择而是合规选择。云灾备在这一点上天然处于劣势，数据托管在第三方，主权边界模糊。我见过一个电力客户，就因为调度数据不能出园区，最后放弃了已经谈了一半的云灾备方案，转而自建异地机房。</p>

<p><strong>预算形态</strong>最后落地。CAPEX 买一体机，前期投入大，三年折旧后边际成本低；OPEX 走云订阅，起步轻，但用得越久累计支出越高。我通常按三年周期折算对比，年增量超过 20TB 的场景，本地容灾备份的三年总成本往往低于云侧订阅。这里有个反直觉的点：云备份的单价看起来便宜，但恢复时的出流量费用经常被忽略。某云厂商的归档存储每 GB 每月不到一毛钱，但恢复取回时每 GB 出流量要几毛，50TB 全量恢复一次光流量费就上万。签约前一定把恢复路径上的所有费用项拉出来算一遍。</p>

<p>把这几层叠起来看，结论其实不复杂。云灾备的优势在弹性扩容和成本形态，异地归档场景它确实更划算，长期冷数据放对象存储，每 GB 成本比自建低得多。本地容灾备份的优势在恢复速度和主权清晰，异地容灾走 150km 以上同步、DNS 切换 8 到 18 秒这套机制，是云侧带宽回传比不了的。两者不是替代关系，是分层关系：本地保恢复，云侧保归档。</p>

<p>一个避坑提醒：别拿云备份的 RPO 承诺直接当业务 RTO 用。很多云产品的 SLA 写的是数据持久性，不是恢复时间，这两件事差着好几个数量级。持久性 99.999999999% 说的是数据不丢，不是说你五分钟能拿回来。签约前一定要做一次真实恢复演练，把带宽、并发、解压、校验全跑一遍，数字才算数。演练的时候还要注意一点：别只测小文件，要拿真实生产数据集测，小文件恢复快不代表大库恢复快，IO 模式和并发压力完全不一样。</p>

<p>选型这件事，先算账，再谈架构。数据量、RPO/RTO、合规、预算，四个维度过一遍，答案基本自己就浮出来了。如果四个维度指向不同方向，那就老老实实做分层——本地扛恢复，云侧扛归档，各干各擅长的事。</p>

<p>作者：刘知远</p>

<p>发布日期：2026年11月3日</p>