灾难恢复
DR 站点选择
灾难恢复站点需要足够远的距离以避免灾害波及，但又要足够近以支持所需的复制模式。这两个约束加上候选市场的实际设施存量，在任何供应商对话前就决定了最终候选。以下工具基于真实数据对这三个因素进行验证：实测的14个市场间往返时间及1629个设施的目录。
DR 配对查询器
选择您的主市场。候选项按往返时间排序，并显示各距离支持的复制模式。
| DR 候选项 | RTT | 支持的复制模式 | 市场内的设施数 |
|---|
RTT 数据基于已发布的云端跨地域测量（Azure、cloudping.co）——相关来源请见延迟矩阵。托管设施之间的光纤路由走向类似；在承诺RPO前，请与运营商核实具体配对。
复制模式由物理特性决定
光在光纤中每毫秒往返时间内约传播 100 公里。这个单一数字决定了架构：同步复制需要往返时间在应用程序的写入预算范围内，这限制了距离约 100 公里——而所有更远的距离都必须是异步的，无论存储层的承诺如何。
| 模式 | RTT 预算 | RPO | 这意味着什么 |
|---|---|---|---|
| 同步 | ≤ ~10 ms | 零 | 每次写入都必须在两个站点确认后，应用才能继续。事务延迟包含往返时间，因此距离成为应用开销。 |
| Near-synchronous | ~10–25 ms | 秒 | 写入连续流动，确认要求放宽。这是城市相邻对的实际选择，例如法兰克福–阿姆斯特丹或新加坡–吉隆坡。 |
| 异步 | 任意 | 分钟 | DR站点按复制间隔延迟。这是长距离上的唯一选择——对于大多数工作负载来说也是正确的选择。 |
四种DR模式，诚实定价
成本表示为主站点运营成本的占比。模式决定RTO；复制方式决定RPO；二者的组合决定所需预算。大多数组织为不同工作负载等级采用差异化的模式——业务关键路径采用主动-主动，可容忍延迟恢复的工作负载采用备份-恢复。
| 模式 | RPO | RTO | 相对主站点的成本 | 运作方式 |
|---|---|---|---|---|
| 备份和恢复 | 小时–天 | 天 | ~5% | 备份异地复制，仅在灾难发生时构建基础设施。便宜、缓慢，但恢复过程从未被测试。 |
| 试点轻 | 分钟–小时 | 小时 | ~10–20% | 核心数据复制到最小化占用空间，在故障转移时扩展。DR 站点中的几个机柜承载数据库；计算资源按需到达。 |
| 热备 | 秒–分钟 | 分钟–小时 | ~30–50% | 一个按规模缩小的生产副本持续运行。故障转移是升级，而不是构建。 |
| Active-active | ≈ 0 | ≈ 0 | 100%+ | 两个站点都承载流量；失去其中一个是容量事件，而非故障。需要应用程序为此特别设计——改造等同于重写。 |
使用 托管成本估算器 按目标市场的 指数费率 评估备用占用空间的成本。
真正失败的是什么
灾难恢复规划倾向于假设地震。事件日志 显示真实威胁更接近电表：电网扰动、UPS 电池火灾、冷却故障和网络硬件故障。位于同一电网、同一洪泛地带、同一运营商酒店后方的 DR 站点几乎无法防护这些情况。最近的事件：
- 2026-09-01Google Cloud: network degradation in us-central1-b takes down 15 products for up to 4h08mus-central1-b (Council Bluffs, Iowa)
- 2026-08-31Microsoft 365: authentication-configuration fault disrupts Exchange Online, Teams, SharePoint and Defender XDR for multiple daysGlobal (Microsoft 365 cloud services)
- 2026-08-27Proton: total cooling failure at Frankfurt datacenter takes down Mail, VPN, Drive and Pass for 2h18mFrankfurt, Germany (Proton-operated datacenter)
- 2026-08-20Google Cloud us-west1 (Oregon) region: multi-service degradation for about 3h40mus-west1 region (The Dalles, Oregon)
- 2026-08-17GitHub outage: retry storm and Central US datacenter network saturation cause 7h47m disruption to Issues, PRs, Actions and CopilotCentral US datacenter region, with failover traffic routed to Northern Virginia
DR 站点检查清单
- 与主站点不同的公用电网 — 核实实际变电站，非营销宣传
- 位于主站点洪泛地带和地震区之外
- 光纤路由多样化：两个站点不能共享运营商酒店或光缆登陆点
- 已测量的 RTT，不是估算值 — 且在您选择的复制模式的预算范围内
- 设施获得合规所需的认证等级 — 查看认证目录
- 容量可按合同扩展：无法在真实灾难期间扩容的灾难恢复站点形同虚设
- 远程代操服务有合同规定的响应时间 — 区域性事件期间无需飞往现场
- 故障转移在上线前进行端到端测试，之后每年测试一次 — 计划不等于能力
常见问题
主数据中心和灾难恢复数据中心应相距多远？
要远到不共享灾难，又近到适合你的复制模式。基本要求是独立电网、独立洪泛区和独立运营商路由 — 实践中需要50 km或以上。同步复制将距离上限设定在约100 km（往返延迟约10 ms）；异步复制完全消除上限。亚太地区许多监管机构要求国外灾难恢复，这需要异步复制。
RPO和RTO之间有什么区别？
RPO（恢复点目标）是你能承受的数据丢失量，由复制模式决定。RTO（恢复时间目标）是你能承受的停机时长，由灾难恢复模式决定 — 备份恢复需要数天，主动-主动恢复只需数秒。成本与两者都有关：将任一指标收紧一个数量级会使灾难恢复预算大约翻倍。
同步复制能否跨国工作？
只有相邻国家之间才可以。新加坡–吉隆坡的往返延迟约8 ms，支持同步；法兰克福–阿姆斯特丹约11 ms属于临界。任何超过~25 ms的都属于异步领地，无论存储厂商数据表如何说明 — 每次写入都要经历往返延迟，应用团队会比灾难恢复团队更先感受到。
什么实际上导致数据中心停机？
我们的事故日志主要记录电力事件（公用事业中断和UPS故障）、火灾（锂电池室频繁出现）、冷却故障和网络硬件故障 — 而非区域性自然灾害。实际含义：同一城市同一电网上的灾难恢复站点几乎无法防止设施级别实际发生的任何事故，而邻国站点则能防止几乎所有这些事故。
公有云是否是托管工作负载的有效灾难恢复站点？
对于备份恢复和试点灯模式，通常可以 — 你只在待机容量运行时付费，这正好符合云定价模式。问题在于回程出站流量和运维开销：将托管基础设施恢复到云意味着永久维护两个部署目标。测试完整恢复，而非只测试复制。
应该多频繁测试灾难恢复？
完整故障转移至少每年一次，组件恢复每季度一次，以及每次重大基础设施变更后。未测试的灾难恢复计划是文档，不是能力 — 事故日志表明故障集中在只有真实测试才能验证的机制上（电力切换、冷却重启）。
寻找灾难恢复市场？
告诉我们主站点、所需的RPO和合规框架。我们将提供可行灾难恢复市场中的设施、基准定价以及值得向每个运营商提问的关键问题。