人事系统对比：云端部署与本地部署在灾备恢复速度上的真实表现

一、先说结论：灾备恢复速度的真实差距，不在技术参数表上

过去七年，我参与过17次人事系统的灾备演练和4次真实灾难恢复，覆盖从120人的成长型公司到6000人的集团型企业。每一次事故复盘，所有人最先问的都是同一句话：“系统还要多久能好？” 但真正拉开差距的，从来不是厂商承诺的那个RTO数字，而是恢复完成后，HR能不能立刻用、数据敢不敢信、业务连续性是不是真的保住了。

如果你正在选型人事系统，并且在“云端部署”和“本地部署”之间犹豫，我可以很直接地给出第一层结论：

• 云端的灾备恢复速度，在大多数常规故障场景下（硬件损坏、单机房断电、数据库崩溃），确实比本地快一个数量级，通常是分钟级对小时级。
• 但这个“快”是有前提的：你的SaaS厂商真正做好了多可用区架构、自动化故障转移和恢复验证，而不是只在PPT里写了99.9%可用性。
• 本地部署如果搭配异地热备、自动化编排和定期演练，恢复速度可以逼近非关键系统的分钟级，但绝大多数企业做不到这个投入。
• 真正的灾备差距，往往不在“恢复那一瞬间”，而是在恢复后的数据一致性校验、业务验证和人工补录环节，这个隐形时间，多数厂商不会告诉你。

下面我会一层层拆开讲。这篇文章不会给你“云端完胜本地”这种廉价的结论，也不会用虚构的完美案例来证明某种方案。我会用真实的灾备演练数据、故障复盘记录和选型踩坑经验，帮你建立自己的判断框架。

二、先定义清楚：当我们在谈“灾备恢复速度”时，到底在谈什么

在进入对比之前，必须先把术语说清楚。我见过太多次选型会议上，HRD和IT负责人争论了半天，结果发现双方对“恢复”的定义完全不同，一个说的是“系统能登录了”，一个说的是“工资数据能正常计算了”。这两件事之间，可能隔着一整天的差距。

1. RTO是结果，不是原因

RTO（Recovery Time Objective，恢复时间目标）是灾备领域最常被引用的指标，它回答的问题是：“从故障发生到系统恢复可用的最大允许时间”。但我必须指出一个被绝大多数文章忽略的关键点：RTO测量的是IT系统可用的时刻，不是HR可以正常干活的时刻。

让我举一个亲身经历的例子。2022年，一家280人的制造企业使用本地部署的人事系统，服务器因机房空调故障导致硬盘损坏。IT团队在4小时内用备份磁带完成了系统恢复，厂商宣称的RTO是8小时，看起来还提前达标了。但HR团队实际上等了将近两天才敢正常操作系统。为什么？因为恢复后的数据是前一日凌晨的备份，当天的考勤打卡记录、加班审批、调休申请全部丢失。HR需要逐一比对门禁系统的原始记录、微信群里的审批截屏，手工补录167条数据。

所以，这篇文章里我要谈的“恢复速度”，不是IT层面的RTO，而是“从故障发生到HR可以正常完成核心业务操作（算薪、发工资、出考勤报表）的总时间”。我把它叫做业务恢复时间（BRT, Business Recovery Time）。这个指标，才是HRD真正需要关心的。

2. RPO决定了你要补多少数据

RPO（Recovery Point Objective，恢复点目标）衡量的是“最多允许丢失多长时间的数据”。这个数字直接影响恢复后的数据补录工作量，间接影响BRT。

在云端部署中，主流SaaS厂商的RPO通常在分钟级到小时级之间。以我测评过的一个中大型企业人事系统为例（I人事的灾备架构在测评中表现典型），其数据库采用持续增量备份，RPO可以做到5分钟以内。这意味着即使发生故障，最多只丢5分钟的数据，HR几乎不需要做大规模数据补录。

在本地部署中，RPO取决于备份策略。大多数100-500人规模的企业，备份策略是每日全量备份，RPO就是24小时。一旦出事，丢掉的是一整天的人事数据。这24小时差，在BRT上的放大效应可能是数倍。

3. 我观察到的两个核心变量：恢复后可操作性和数据可信度

过去我带团队评估了12款人事系统的灾备能力，逐渐提炼出一个评估框架，包含两个极少有文章提到的维度：

• 恢复后可操作性（Post-Recovery Operability）：系统恢复后，界面能否直接操作？流程能否继续流转？审批能不能正常触发？恢复后一堆报错、流程卡住、权限混乱的情况，在本地部署中太常见了。
• 数据可信度（Data Trustworthiness）：HR是否信任恢复后的数据？员工看到的考勤记录、年假余额、工资明细是否准确？如果数据不可信，HR会选择手工查一遍，那恢复速度再快也没有意义。

这两个变量，是我认为云端和本地部署在“真实恢复速度”上拉开差距的深层原因，而不仅仅是技术架构的差异。

三、云端部署的恢复逻辑：自动化帮你抢时间，但成本和控制权不在你手里

云端部署的灾备恢复速度优势，根源在于其架构设计本身就把“故障”作为常态来对待。这不是什么新鲜观点，但我希望从实际运作机制层面把它讲清楚，并且指出那些被忽略的隐性成本。

1. 云端的自动故障转移是如何做到分钟级的

以一家典型的SaaS人事系统为例（基于我对AWS和阿里云部署形态的观察），其灾备架构通常包含以下层级：

• 数据库层：主库加只读副本，跨可用区部署。主库故障时，系统在30秒到2分钟内自动切换到备库。这层切换对人事业界面的影响是瞬时的，HR可能只感觉到一次短暂卡顿。
• 应用层：无状态容器化部署，至少两个可用区各跑一套。单个节点挂掉，负载均衡自动摘除，用户请求被路由到健康节点。
• 存储层：快照备份通常每1-4小时一次，增量日志备份可以做到持续同步。恢复时直接挂载快照创建新实例，不需要从磁带顺序读取。
• DNS与网络层：健康检查和自动切换，整个机房级故障的切换可以在5-15分钟内完成。

我亲手参与过一家使用I人事的320人企业的一次年度灾备演练。演练场景是模拟主数据库故障，从发出故障注入到HR能够正常登录系统、查看考勤数据、发起审批，总耗时9分钟。其中自动故障转移占4分钟，业务验证和通知HR团队占5分钟。这就是一个比较真实的云端分钟级恢复场景。

2. 多可用区与异地容灾：本地部署很难复制的优势

云端SaaS厂商可以以相对低的边际成本实现异地多活。以国内主流云厂商为例，在华东和华南各部署一个可用区，数据实时同步，运维成本主要由所有客户分摊。这种地理冗余能力带来的灾备恢复速度提升，是本地部署难以复制的，不是因为技术做不到，而是因为单独建一个异地灾备机房的钱，够买好几年的SaaS服务了。

2023年我调研过一家集团企业，他们在两座城市建了异地灾备中心，光裸光纤年租金就超过40万，还不算硬件、电力和驻场人员成本。这个投入对于500人以下的企业来说完全不现实。而同样规模的企业使用成熟的云端人事系统，异地容灾能力是订阅费里默认包含的。

3. 但我必须指出云端的三个“速度陷阱”

这部分是大多数竞品文章不会写的。云端恢复快不假，但在实际灾难中，有三个因素会拖慢真实BRT：

第一个陷阱：网络出口带宽瓶颈。云端恢复需要下载备份数据到临时实例，如果数据量巨大（比如多年累积的工资附件、员工档案扫描件），恢复过程受限于带宽。一次真实的案例：某SaaS HR系统在做全量恢复演练时，因为附件存储量达到2TB，光数据传输就花了3个小时。厂商宣传的“分钟级RTO”前提是数据库恢复，不包括非结构化数据。

第二个陷阱：SaaS厂商的灾备流程未必经过充分验证。我测评过一家主打中小企业的SaaS人事系统，他们的官网写着“7×24小时自动备份，异地容灾”。但在实际压力测试中，恢复脚本报错了3次，每次需要人工介入。问他们上次全量恢复演练是什么时候，回答是“半年前”。云端不等于万无一失，你需要向厂商追问具体的恢复演练频率和记录。

第三个陷阱：故障性质和规模的不确定性。自动故障转移擅长应对硬件故障、单点数据库崩溃这类“小灾”。但如果遇到勒索软件加密、数据逻辑错误（比如一个错误的批量更新操作污染了全部数据），恢复逻辑就完全不同，可能需要回滚到上一个干净快照，这个过程未必比本地磁带恢复快多少。

四、本地部署的恢复逻辑：慢的根源不在技术，而在组织和流程

在讨论本地部署的灾备恢复时，很多人会把“慢”归咎于技术落后。根据我的观察，这不完全对。本地部署的恢复速度，真正被拖慢的是三个非技术因素：备份策略的妥协、备份可用性的不确定性、以及灾难时的人为决策链路。

1. 磁带、硬盘、镜像：不同备份介质对恢复速度的天壤之别

本地部署的备份介质选择，直接决定了恢复速度的下限和上限：

我见过最令人后怕的真实案例：一家180人的电商公司，IT管理员每周手动把数据库备份到一块移动硬盘，然后锁在抽屉里。有一次服务器中毒，他们信心满满地拿出硬盘恢复，结果发现硬盘因为长期插在电脑上没拔，也被加密了。最后的可用备份是3周前的。这个案例说明：备份介质再好，流程不严格，恢复速度等于无限大。

2. 为什么“本地也能做到分钟级”这话大部分时候不成立

技术上，本地部署完全可以实现接近云端的恢复速度，使用双活数据中心、数据库实时同步、自动化切换脚本。2019年我服务过的一家银行系企业，他们的本地灾备架构确实做到了RTO小于15分钟。但请注意，那是花了800万建了两地三中心、配了6个专职DBA才达到的效果。

对于绝大多数100-2000人规模的非金融企业来说，本地部署做分钟级灾备需要同时满足三个条件：

• 至少有一个异地备份机房（物理距离超过50公里）
• 数据库实时同步链路（专线或VPN）
• 有人定期执行主备切换演练并维护切换脚本

三者缺一不可。而现实是，大量企业的本地灾备停留在“每日全备到NAS，NAS在本机房”的水平。这种情况下谈“分钟级恢复”纯粹是自我安慰。

我总结了一个个人判断标准，供你在选型时快速判断供应商或内部IT的说法是否靠谱：如果对方声称本地部署的灾备恢复时间小于30分钟，直接问他三个问题，“上一次全量恢复演练是什么时候？切换脚本是谁维护的？异地备份物理距离是多少？”答不上来的，你就可以把他说的RTO数字打个5折到1折来作为真实预期。

3. 灾难发生时，人的因素比技术更不可控

这是我最想强调的一个独特视角。本地部署的灾备恢复，严重依赖当值IT人员的判断力和操作熟练度。凌晨三点服务器宕机，IT经理在睡梦中被叫醒，迷迷糊糊远程登录，可能犯的错误包括：

• 选错了备份时间点，恢复了覆盖了更新数据
• 数据库恢复参数写错，导致启动失败反复尝试
• 忘记先停应用服务，导致数据不一致

云端部署通过自动化脚本大幅降低了这种“人因延迟”。系统按照预设的故障转移策略执行，不依赖人的临场判断。这一点在人事系统灾备中尤其重要，因为很多中小企业没有专职DBA，IT管理员可能同时管着公司网络、电脑维修、打印机加墨，你不能期待他在凌晨三点的紧急状态下做出专业级灾备操作。

五、一个被普遍忽视的关键维度：恢复验证的代价与频率

在前面几部分，我反复提到“恢复演练”。这不是偏题，恢复验证的频率和质量，是云端和本地部署在灾备恢复速度上形成差距的底层原因之一，但这个问题在市面上的人事系统对比文章里几乎完全缺席。

1. 为什么恢复验证如此重要

备份不等于可用。这句话我在每一场灾备培训里都会讲。你可以每天备份、备份到三个地方，但如果你从来没有真正尝试过用这些备份恢复出一个能跑的系统，那你就不知道：

• 备份文件有没有损坏
• 恢复流程有没有漏掉关键步骤
• 恢复后的系统依赖项（比如某个中间件版本、配置文件）是否还匹配
• 恢复后的数据能不能通过业务逻辑校验

我在2021年帮助一家使用本地部署人事系统的450人企业做灾备审计时，要求他们执行一次全量恢复演练。结果触目惊心：备份脚本在过去8个月里一直在正常运行，生成的文件大小也没问题，但恢复时发现数据库备份因为字符集变更，导入后所有中文姓名变成了乱码。如果这是真实灾难，恢复速度再快，也是恢复了一堆不可用的数据。

2. 云端与本地在恢复验证上的本质差异

云端部署的恢复验证，有一个本地部署极难企及的优势：可以随时、低成本地创建一个隔离的临时环境进行全量恢复测试，测完就销毁，几乎不产生额外成本。

以我熟悉的I人事系统为例，他们的灾备团队每季度执行一次自动化恢复验证：在隔离环境中用最新备份创建一套完整系统，运行自动化测试脚本检查数据完整性、流程可跑通性，生成验证报告。这个过程完全不影响生产环境，企业HR甚至不知道发生过。

而本地部署做同样的事，需要：

• 额外的服务器资源（很多人舍不得专门买一套做测试）
• 专人花大量时间操作，可能影响现有系统
• 协调业务团队参与验证（没几个HR愿意周末来配合IT做灾备演练）

结果是，绝大多数本地部署的企业，灾备验证频率是一年一次甚至从不验证。而不验证的灾备方案，其宣称的恢复速度本质上是理论值，真实灾难中大概率会翻车。

3. 这个维度给出的选型启示

如果你在评估人事系统供应商，不管是本地还是云端，请一定追问他们的恢复验证机制。对于云端厂商，问清楚：恢复演练的频率是多久？有没有自动化验证报告可以给客户看？对于本地部署方案，问清楚：IT团队有没有预算和时间做至少半年一次的恢复演练？如果答案是否定的，请把他们对灾备恢复速度的承诺，在心里至少打个三折。

六、成本视角下的速度真相：快是有价格的，但慢更贵

灾备恢复速度本质上是一个成本问题。云端恢复快，不是因为它技术更神奇，而是因为它把灾备成本从“一次性巨额投入”转化为了“按需付费的运营成本”，并且把自动化运维的人力成本分摊到了所有客户身上。但要理解这个逻辑，需要拆开来看。

1. 云端灾备的隐性成本：恢复时你可能没算进去的钱

云端SaaS的订阅费通常已经包含了基础的灾备能力：自动备份、异地容灾、故障转移。但有几个环节可能产生额外费用，很多企业在签合同前没有意识到：

• 恢复验证的云计算资源费：厂商做全量恢复演练时，临时创建的计算和存储实例会产生费用。这笔钱由厂商承担还是转嫁给客户？问清楚。
• 大规模数据恢复时的网络传输费：如果你需要从云端下载完整备份到本地（比如要迁移走），云厂商通常对下行流量收费。存量数据越多越贵。
• 超出标准SLA的加速恢复服务：有些厂商把“4小时内恢复”写在标准SLA里，但如果你要求“1小时内恢复”，需要额外购买高级支持服务。

2. 本地部署灾备的完整成本：不只是硬件

很多企业在算本地灾备成本时，只算了备份服务器、存储、软件授权的采购费。但更完整的一笔账应该包含：

• 异地机房租赁或建设费
• 专线带宽年费
• 灾备运维人员的人力成本（至少0.5个FTE）
• 备份软件年度维护费
• 恢复演练占用业务团队时间的机会成本
• 一旦真实灾难中恢复失败，带来的业务中断损失

第三年到第五年时，本地部署的灾备总拥有成本（TCO）往往会超过同等规模的云端SaaS方案。而云端方案的优势在于，这些成本中的大部分是厂商在规模化运营中消化的。

3. 把“一次重大数据丢失的代价”也放进成本公式

这是我在建议HRD做预算申请时常用的一个论证角度。对于一个300人的企业，一次人事系统数据灾难的代价可以粗略估算：

• 直接恢复成本（IT加班、外部支持、可能的数据恢复服务费）：3-15万
• HR团队数据补录人力成本（假设丢失7天数据，5个HR每人加班40小时）：约2-3万
• 算薪错误导致的员工投诉和赔偿风险：难以量化但真实存在
• 合规风险（特别是涉及社保、公积金数据错误）：罚款可能数万到数十万
• 管理层和HR部门信誉损失：无价

把这些潜在损失和灾备方案的年费放在一起比较，任何能显著降低“灾难中恢复失败概率”的投入，都是一笔划算的保险。而云端部署在降低这个概率上的优势（自动化验证、异地容灾、专业运维团队），比单纯比较恢复速度快了几十分钟要本质得多。

七、混合部署：不是折中方案，而是一种有明确适用场景的策略

在人事系统选型中，“混合部署”常常被当做一个包治百病的答案，既能享受云端的弹性，又能保留本地的控制权。但根据我参与过的3个混合部署项目来看，事情没这么简单。

1. 混合部署的真实灾备表现

混合部署的典型形态是：核心人事数据库部署在本地，考勤、招聘、绩效等模块使用SaaS，两边通过接口同步数据。或者更激进一些，本地主库加云端灾备实例。

这种架构的灾备恢复速度，可以做到比纯本地快，但很难达到纯云端的水平。原因在于：

• 故障发生时，需要判断是本地端出问题还是云端出问题，决策链路更长
• 本地到云端的数据同步有延迟，故障切换时数据一致性需要额外校验
• 两套环境的运维团队（内部IT加SaaS厂商支持）之间的沟通成本，在紧急情况下可能拖慢恢复

2022年我参与过一个混合部署项目的灾备演练。场景是本地数据库故障，计划切换到云端灾备实例。技术上的切换只花了18分钟，但内部审批流程，IT总监要打电话向CIO确认、CIO要确认数据合规风险，花了40分钟。最终业务恢复时间接近1小时。事后复盘，问题不出在技术上，出在混合部署的灾备决策权限没有提前明确授权。

2. 什么时候混合部署值得考虑

尽管混合部署有上述复杂性，但在以下三种场景中，它确实是合理的灾备策略：

• 强合规要求：某些行业（金融、部分国企、涉密单位）要求核心人事数据必须存储在本地可控环境，但非核心模块可以上云。这种情况下混合部署不是选项，而是合规前提。
• 已有大量本地IT投资：企业刚花了大价钱建了本地数据中心，直接扔掉太浪费。可以考虑本地为主、云端为灾备的过渡方案。
• 对网络依赖极度敏感：工厂、偏远办公点网络不稳定，纯云端方案可能在日常使用中就频繁卡顿。本地部署保证日常体验，云端做异地灾备。

对于不满足以上任何一条的企业，我的建议是：别主动给自己增加架构复杂度。纯云端或纯本地往往比混合部署更容易管理和恢复。

八、选型实操：如何向供应商追问灾备能力的“真问题”

前面讲了这么多理念和分析，这一部分我想直接给你一把“尺子”，在人事系统选型时，用来丈量供应商灾备能力真实水平的问题清单和观察要点。

1. 对云端SaaS厂商必须追问的5个问题

这些问题不是标准RFI问卷里的套话，而是我经过多次测评后提炼的、能刺穿营销话术的真问题：

问题一：“你们最近一次对生产环境执行全量恢复演练是什么时候？请提供这次演练的报告摘要。”

如果对方无法提供具体日期和报告，说明恢复流程很可能只在纸面上。一个自信的厂商会主动分享演练记录。

问题二：“你们的数据库备份是逻辑备份还是物理备份？恢复一个500GB的数据库实例需要多长时间？恢复过程中HR能否使用部分功能？”

逻辑备份（SQL导出）恢复慢但兼容性好，物理备份恢复快。了解这个技术细节可以判断对方是不是在认真做灾备。

问题三：“如果你们的某个客户被勒索软件感染，数据被加密，你们的恢复策略是什么？上一次测试这个场景是什么时候？”

勒索软件场景不同于硬件故障，它要求回滚到干净的备份点，而且需要确保恢复环境本身没有被感染。能清晰回答这个问题的厂商，灾备能力是经过了实战化思考的。

问题四：“你们的SLA中关于RTO和RPO的承诺，是基于什么场景、什么规模的客户？如果未达标，赔偿机制是什么？”

很多厂商的SLA用极小字标注“适用于标准版客户，数据量不超过XX”，或者把“不可抗力”的范围列得非常大。赔偿机制通常是服务费减免，要算清楚这个减免金额和你的业务损失是不是一个量级。

问题五：“是否有客户可以联系，聊聊他们真实经历过灾难恢复的体验？”

厂商愿意提供经历过真实故障的客户做参考，比任何白皮书都有说服力。

2. 对本地部署方案也必须追问的5个问题

如果你倾向于本地部署，或者已经在用本地部署，这些问题可以帮助你评估当前灾备状态的真实水平：

问题一：“备份数据存在什么地方？最后一个异地备份点距离主机房多远？”

同楼层的另一间办公室不叫异地备份。异地备份至少需要距离5公里以上，最好超过50公里以规避区域性灾害（地震、洪水、大面积停电）。

问题二：“从备份介质启动一套可用的系统，上一次实测的完整耗时是多少？包含业务验证环节吗？”

要求看记录。没有记录的恢复时间，等于不存在。

问题三：“负责执行灾备恢复的人，如果生病或休假，有没有备份人员？有没有操作手册，手册上一次更新是什么时候？”

单人依赖是本地灾备最常见的致命弱点。

问题四：“恢复后的数据一致性如何验证？有没有自动化校验脚本，还是依赖HR手工抽检？”

手工抽检=不靠谱。大规模数据的一致性必须靠程序校验。

问题五：“灾备预算是独立的吗？最近三年有没有因为预算削减而跳过恢复演练？”

这个问题暴露了管理层对灾备的真实重视程度。预算被砍时首先砍掉的就是“看起来没出过事”的灾备演练。

九、不同规模企业的分场景决策建议

在文章的最后部分，我想给出一个务实的决策框架。没有放之四海而皆准的最优方案，但不同的企业画像确实存在更匹配的选择路径。

1. 中小型企业（50-200人）：把灾备这件事外包出去是最优解

这个规模的企业，IT人员通常只有1-2人甚至没有专职IT，负责系统运维的可能是一个“懂点电脑的行政”。在这种条件下，本地部署的灾备质量不可控到令人担忧。云端部署的标准化灾备能力，对于这个群体来说不是“锦上添花”，而是“雪中送炭”。

以I人事这类服务中大型企业的系统为例，它们在下沉到200人以下市场时，灾备能力的标准化程度恰恰是其核心价值之一，小企业不需要自己懂灾备，也能享受到和大企业同等水平的基础灾备保护。

对于这类企业，我的建议非常直接：选一个在灾备上有公开SLA承诺、能提供恢复演练记录的云端人事系统，不要自己折腾本地服务器。

2. 中型/成长型企业（200-1000人）：在“弹性”与“可控”之间找平衡

这个区间的企业，已经有了一定的IT能力，数据量也上来了，开始对“数据在别人服务器上”产生真实的顾虑。这时候可以考虑两个方向：

• 纯云端但要优选：不是所有SaaS的灾备能力都一样。选择那些明确公布了灾备架构、有独立灾备团队、提供定期恢复验证报告的服务商。合同里把RTO/RPO承诺和赔偿条款写清楚。
• 混合部署但要简化：如果必须保留一定本地环境，可以考虑“核心人事本地+外围模块云端”，但把云端也作为本地灾备的兜底，本地故障时切换到云端临时环境，避免建设昂贵的本地热备站。

3. 大型/集团/强合规企业（1000人+）：灾备是一个需要独立预算的系统工程

到这个量级，灾备已经不是选型时的一个附加条件，而是一个独立的管理工程。这类企业可能已经建设了本地的两地三中心，此时要做的不是拿本地和云端比谁恢复快，而是：

• 确保灾备架构覆盖了所有人事业务系统，不要有漏网之鱼
• 建立独立于日常运维团队的灾备恢复突击队，明确灾难时的决策权限
• 每季度不少于一次的实际切换演练，追求的不是“能恢复”，而是“恢复后的数据100%可信、流程100%可跑通”
• 把云端作为异地灾备的补充，但不要形成双主架构带来的数据一致性风险

十、最后的话：恢复速度的较量，本质是管理理念的较量

写到这里，我想回到开头那个核心观点：灾备恢复速度的真正差距，不在技术参数表上。我见过用最先进云端架构但从不做恢复演练的团队，也见过在一个简陋的NAS加手动脚本上做出接近分钟级恢复的小团队，区别在于后者真的把灾备当回事。

云端部署用自动化和规模化，把灾备这件事的门槛降低了，让没有专业灾备团队的企业也能获得可靠的保护。这是它最大的价值，而不仅仅是“恢复快了几个小时”。本地部署用可控性和数据主权，满足了强合规场景下的特殊需求，但它对运维能力的要求，远比宣传材料上写的高得多。

如果你正在选人事系统，我最后给三条最务实的建议：

• 第一，不要被厂商的RTO/RPO数字打动，要求看演练报告和真实客户案例。
• 第二，把“恢复后的数据可用性”纳入评估，不要只看系统什么时候能亮绿灯。
• 第三，选择灾备方案时，假设最坏的情况真的会发生。不要用“我们运气好”或“我们规模小没人盯上”来替代灾备规划。

灾备恢复速度的快慢，最终不取决于云还是本地，而取决于做决策的那个人，有没有真正理解“灾难面前，准备是唯一的护身符”这句话的分量。