正在加载，请稍候
2026 年 9 月 AWS 中东区域数据不可恢复，把容灾验收重新推上台面。四类可测检查项、一次恢复演练该留下的产物，以及跨区域冷备的最小配置清单。
2026 年 9 月 29 日 InfoQ 报道：亚马逊云科技确认，仅托管在 UAE me-central-1 的 mec1-az2 可用区、以及整个巴林 me-south-1 区域的客户资源与数据无法恢复。多数讨论停在云厂商的责任划分，真正被暴露的其实是软件定制开发验收单上那几行空格。
亚马逊官方文档把层级写得没有歧义：Region 之间相互隔离，且“we don't automatically replicate resources across Regions”——跨区域复制默认不存在，需要自己配置。来源：Regions and Zones
同一份文档对可用区的定性是“Region 内多个相互隔离的位置”，多可用区部署的价值被明确限定为“protect your applications from the failure of a single location in the Region”。它挡的是机房级故障，并不承诺抵御整个物理设施群被摧毁。
2026 年 3 月的无人机袭击造成三个数据中心受损之后，AWS 先建议客户做跨区域复制，随后建议整体迁出中东。厂商在物理层面的表态，本身就是对“多可用区就是容灾”这个说法的反驳。
把三层目标分开记：单机房、多可用区（位置级）、多区域（地理级）。验收时的第一个问题应该是——你承诺的是哪一层。
| 检查项 | 常见的有问题做法 | 可测口径 |
|---|---|---|
| 备份的异地性 | 备份桶与生产库同 Region、同账号 | 备份存储的 Region 与账号均不同于生产，跨账号 + 跨区域各留一份 |
| 恢复演练的频率与留痕 | 从未演练，或只在测试环境点过一次“恢复” | 每季度至少一次生产级演练，产出实测恢复耗时与签字报告 |
| 依赖项的跨区域可用性 | 只备份了数据库 | DNS、密钥与证书、镜像仓库、对象存储、消息队列、第三方回调地址逐项列清单 |
| 供应商声明与合同 SLA 落差 | 把可用性 SLA 当成灾难保障 | 服务协议写明灾难排除条款，以及数据不可恢复时的取证与赔付口径 |
第一项最容易被放过：同区域备份等于没备份。区域级事件一旦发生，备份桶和生产库一起消失，这是 2026 年 9 月那条消息里最直接的教训。
第二项的症结在留痕。演练没有记录就没有证据，验收方判断不了 RTO 是否达标，复盘时也找不到失败点。我们在小程序交付复盘里提过同一个逻辑：交付的是一个可验证的行为，而不是一份声明。
第三项在真实恢复现场暴露得最晚。数据库拉起来了，DNS 记录还锁在原账号、容器镜像仓库还在原 Region、证书私钥随密钥服务一起不可用——业务照样起不来。
第四项是合同工程。多数云 SLA 覆盖“服务可用性”，对“数据可恢复”往往只承诺尽力，而灾难场景常常就写在排除条款里。立项前的尽调问题清单，可以参考这 12 个 CTO 尽调问题。
RTO 是故障发生到业务恢复可用的时长，RPO 是可接受的数据丢失时间窗。这两个数不进验收单，就永远只是一句口头承诺。
AWS 的容灾白皮书把可选策略分成四档：backup and restore、pilot light、warm standby、multi-site active/active，并给出选择依据——如果你的“灾难”定义已经超过单个物理数据中心受损，就该考虑后三档。同一份白皮书还反复强调：必须定期评估并测试容灾策略，才能在真正需要时有信心触发它。来源：Disaster recovery options in the cloud
一个普遍被省略的动作是无主库演练：把生产读流量切到恢复环境跑一轮。只验证“数据能读出来”，等于没验证业务能不能跑。
另一个细节来自白皮书的建议——故障切换尽量只用 data plane 操作。控制面（配置类 API）的可用性设计目标低于数据面，灾难现场靠控制面改配置，很可能改不动。
不是每个项目都需要双活，但每个项目都该在验收单上写清容灾口径。跨区域冷备是成本最低、最容易写进验收的一档，最小配置如下：
里程碑上，我们通常把三件事排进交付计划：备份异地性在开发中期完成、第一次恢复演练放在 UAT 结束前、演练频次写进运维交接文档。这样容灾就不是上线前一天的补丁。它和配置债清理属于同一类工作——都是平时看不出收益、出事时才知道贵的那部分。
报价要单列。把容灾拆成备份存储、跨区域流量、演练人力三项，客户能看懂多出来的钱花在哪；打包进“服务器费”里，第一轮砍预算就会被砍掉。蓝曜炬辉在交付计划里就是把容灾拆成可核对的条目，而不是写在方案最后一页的承诺。
需要照着清单逐条对的项目，可以先看我们已交付的案例复盘：交付案例。
一个电商后台项目，验收单上写的是“备份任务每日执行成功”，日志确实全绿。三个月后运营误删了一张核心表，按流程触发恢复。
结果是：可用快照是 7 天前的，增量日志因为成本原因没开，恢复脚本还引用了半年前的旧版镜像。承诺 15 分钟的 RPO，实际丢了 7 天数据，返工三周才补齐对账。
复盘结论很朴素——备份证明的是“有没有”，恢复证明的是“能不能”。验收单上只有前者，出事时手里就没有证据。这也是软件定制开发里最常见的一次返工。
够挡 Region 内的单点位置故障，不够挡区域级或物理设施群损毁。要不要加跨区域，取决于业务对小时级甚至天级中断的容忍度。
按业务损失倒推，而不是按技术难度正推。交易、支付类通常压到分钟级，内部管理系统可以接受小时级，两者预算差一个数量级。成本结构上的差异，可以对照这份报价与选型拆解。
多数 SLA 针对服务可用性，灾难场景常列在排除条款，赔付上限一般是服务费抵扣。数据能不能回来，属于你自己的责任范围，需要写进与厂商的服务协议。
季度是常见底线，关键系统建议月度；任何一次架构变更后都要补一次演练，因为依赖项清单很可能已经变了。
把检查项、频次、演练产物、报告交付时间写进验收条款，而不是只写“乙方保证数据安全”。可核对才可追责。
容灾验收的具体条目和演练节奏，需要按你的系统依赖画一遍才能定，欢迎联系我们对着架构图过一轮。