备份成功却恢复不了，容灾验收该验什么？

验收要覆盖完整业务链，用7问核对恢复证据，把预算投向真正阻塞业务的缺口。

把全绿报表变成业务恢复证据，先验一条关键业务链。对已有备份、预算有限的IT负责人，我会先做受控恢复，再决定是否加副本。7问验收单可以把钱该投留存、依赖还是演练分清。

用同一个假设订单系统演练：1 TB数据、20 GB待回放日志，历史订单能查，新订单却提交失败。备份任务只证明约定范围的复制完成；验收还要追到提交、库存和账务。本例的容量、目标、资源和留存数字均为演练设定。

这套做法适合已有备份、能安排受控隔离恢复的存量系统。先由业务方选定最低服务范围。如果已经确认唯一副本损坏，应先保全剩余数据、补齐可用副本。

第1步，把“下单成功”写进验收终点

把验收记录拆成4种状态：备份成功，留下副本标识和任务记录；数据可读，留下恢复后关键表的读取结果；应用可启动，留下版本和健康检查；业务可办理，留下交易、对账和负载结果。

最值得补的用例是“登录→下单→查状态→核对库存与账务”。健康检查可能只探进程，没有执行事务提交。登录页截图只能证明入口通了。

验收终点是约定业务重新可办，而不是数据库恢复任务结束。

本例把RTO（恢复时间目标）定为2小时，RPO（可容忍的数据丢失时间窗口）定为15分钟。最低服务是每分钟完成50笔下单，连续验证10分钟；查询、库存与账务同步验，报表导出可暂停。这些是待业务方签认的目标。

故障演练从注入故障导致业务中断时开始计时，到约定业务能力恢复并验证通过时结束。发现、授权、资源准备、取回、解密、回放、启动和业务验证分别留时戳。并行步骤沿真实时间轴统计。

若只从点击“恢复”开始计时，就把成绩标为恢复作业耗时，另列未测的发现和决策阶段。RPO则用故障参考时刻与经对账确认的业务恢复点核对，别用最新备份文件的生成时间替代。

留下这份双方认可的口径记录，后续测试才能比较。跨系统数据各有进度时，还要记录未完成交易及补偿办法；单库时间追得最新，业务账仍可能断在中间。

▲ 入口亮了、历史订单能查，仍要验证新交易与库存账务结果。

第2步，沿依赖排恢复顺序，先解开启动环

先测解密。例如取密钥轮换前、后的2份备份，用同一个灾时恢复身份分别解密。记录副本编号、对应密钥标识、恢复身份与解密结果。旧副本失败时，先查历史密钥与授权；只重跑最新备份，暴露不了这个缺口。

把恢复顺序写成依赖关系：恢复身份与授权→副本读取；历史密钥与授权→解密；基础备份与连续日志→数据库目标点。应用包和配置可以并行准备，等数据库、网络、域名解析与认证就绪后再启动应用。

消息系统若是启动依赖，就与数据库一起提前恢复；消费位点校准后再放开消费。接通外部测试通道，再做交易、对账和最低能力验证。将这些关系汇成恢复顺序图，标明恢复来源、负责人和阻塞点。

以PostgreSQL 17为例，基础备份要配上从备份开始覆盖至目标点的连续WAL（预写日志）。用逻辑导出文件替代物理基础备份，再接WAL回放，这条恢复路径走不通。

配置也要另有版本和恢复来源。日志回放恢复数据库变更，手工改过的配置文件要单独核对。数据库扩展、应用镜像及配置版本应与恢复点对应，避免拿今天的应用直接连接旧结构。

还要找依赖环：密钥服务要先认证，认证库却等待解密恢复。为这种环准备独立、受控的引导路径和应急身份，并实际走通。只写“联系管理员”，相当于把恢复时长交给临场协调。

▲ 数据库之外，身份、密钥、配置与运行依赖也要就绪，应用才能走到业务验证。

第3步，按覆盖范围安排抽样、全量和业务测试

预算有限时，我会把抽样恢复做成常规检查，把隔离全量恢复留给正式验收和关键变更后的验证。业务验证叠加在恢复环境上，三者承担不同任务。

抽样按对象、恢复点和版本分层，纳入经历密钥轮换的旧副本。支持对象级恢复时，可少占算力和窗口。采用PostgreSQL物理备份时，要先恢复整个数据库集群，再抽验表；省下的是校验范围，存储仍按整库准备。

PostgreSQL 17的pg_verifybackup校验基础备份清单、校验和及所需WAL，之后仍要实际恢复。检查WAL应使用匹配备份版本的工具；清单范围之后、通向目标点的归档日志另行核验。

隔离全量恢复要装下选定业务所需的全部数据、日志和运行依赖。先落实测试窗口。临时存储按数据文件、回放临时空间和空间峰值准备，算力对齐灾时配置；磁盘配额按解压后的规模核算。

本例数据库恢复机限定8 vCPU、32 GB内存、2 TB可用SSD空间、1 Gbit/s网络，恢复完整1 TB数据并回放20 GB日志。存储型号、限速和共享争用也入档；这些是测试输入，是否足够要看空间峰值和业务实测。

抽样负责发现局部坏点，全量恢复验证规模，业务测试确认交易结果。

业务测试由技术与业务人员共同执行。例如下单请求超时后，用同一个请求号再提交1次，预期仍只有1笔有效订单和1次库存扣减。按前述负载目标验证，外部支付走受控测试通道，避免真实扣款。

使用外部系统替身时，把覆盖范围写到结果里：本地请求与响应已验证，真实依赖仍待联调。留下测试用例、资源曲线、分段时戳和未测项，才能判断下一笔钱该补环境还是补协作。

▲ 抽样查局部、全量验规模，交易结果还要叠加业务测试。

排练最容易失真的是预置条件和生产依赖

提前下载副本、解密、建好机器，确实能缩短现场操作。但长期预置能力要证明灾时可用，临时准备则计入恢复过程。否则报表压短的是计时范围。

隔离环境仍可能借用生产认证、域名解析或密钥服务。按声明的故障域阻断这些依赖，再测恢复路径。查询成功后核对实例标识与连接目标，防止把误连生产库当成恢复成功。

本例承诺30天内可按时间点恢复，却只留7天日志。选14天前的一次全备，目标定在该备份完成后的下一笔已提交订单：逐段检查所需归档。只剩全备时，先实测能否恢复到一致状态，再按可达点签字并补日志留存。

启动应用前先阻断生产出口，停住自动消费者和定时任务，换上测试身份，再逐项放行。演练结束按授权清理测试数据和资源。这些安全步骤应写进操作顺序，预留人员和时间。

用7问验收单签清范围，待补测项单列

通过条件应落到演练前约定的业务范围、最低处理能力、RTO和RPO。关键外部依赖尚未联调，就标记完整业务验收待完成，已验证部分单独签字并指定补测责任人。

对账用1笔购买2件商品的测试订单：库存只扣2件，重复回调后同一业务流水只入账1次。复式记账按成组分录核对借贷平衡。再查订单标识、金额汇总和状态分布；差异处理完由业务方确认。

这张表可直接用于评审。表头填写统一口径，末列填写通过／未通过／未验证、证据编号和责任人。证据保存在受控位置。

业务恢复验收单：业务范围____；故障域____；目标恢复点____；RTO____；RPO____；最低处理能力____；数据／日志规模____；演练环境____；日期及验收人____。

验收问题

应交证据

通过口径

结论／编号／责任人

1. 能恢复到哪个业务时间点？

故障时刻、恢复点、对账结果

丢失窗口满足RPO，跨系统可核对

待填

2. 所需日志是否连续？

基础备份匹配、日志范围、回放结果

已完整回放至目标点

待填

3. 灾时身份能解开历史副本吗？

身份授权、历史密钥实际解密结果

声明故障域下可授权、可解密

待填

4. 关键依赖按什么顺序恢复？

依赖图、配置版本、外部联调记录

关键依赖实测通过；替身项待联调

待填

5. 恢复时放得下，恢复后扛得住吗？

数据日志规模、空间峰值、负载结果

目标资源满足空间及最低业务能力

待填

6. 业务账能对上吗？

交易对账、重试与补偿结果

差异按约定闭合，业务方确认

待填

7. 全过程用了多久？

起止与分段时戳、等待、验证签字

相同计时口径下满足RTO

待填

日志过期补留存，归档失败补采集；解密或启动受阻补依赖。材料齐全却没人走通，先投演练；容量和吞吐缺口则用灾时资源实测定位，再扩对应资源。预算先修复已验证的恢复缺口，再扩大容灾投入。

预算只够加副本或建独立验证环境，你选哪项？留言给一个决定性约束。

IT架构师联盟

面向企业架构师与技术负责人的专业号：讲企业 IT 架构的选型与演进，把关键决策的取舍和代价讲清楚。