系统恢复以后怎样证明业务已对齐

ERP 恢复后能登录，接口也重新连接，仓库仍不敢继续发料。故障前一笔扣料已经执行，但发送方没有收到回执；队列里还有退料消息。把积压消息重新发送一遍，可能补上缺失，也可能再扣一次库存。

本篇完成 S08 的恢复演练。REC-01 是独立模拟样本，数量与故障条件均为教学设定，没有执行真实数据库恢复。样本校验用于验证账目和重放规则，不表示备份、网络或生产系统通过了灾备测试。

先留下恢复点和业务截止位置

数据库备份完成时间、恢复到的事务位置、消息消费位置和业务单据截止范围需要分别登记。跨系统恢复到“上午十点”，无法单独证明各系统包含了相同业务事实。一个系统可能已经提交单据，另一个还在等待接口。

PostgreSQL 17 文档说明，时间点恢复依赖基础备份与连续 WAL 记录，恢复目标及时间线影响实际恢复范围。它证明该数据库的恢复机制，不能据此承诺所有 ERP 都支持相同操作。连续归档与时间点恢复

本样本冻结工厂 A、物料 MAT-R、库位 MAIN、单位件和三项事务。WMS 来源记录完整保留；ERP 恢复后的目标账和业务键索引一起检查，期初余额均为 100 件。现场实物盘点独立记录，本篇只先核对这组逻辑账。

来源事务	来源动作	应进入 ERP 的变化	恢复后目标情况
RCV-01 / 10	收料 20 件	+20	已有 ERP-T01
ISS-01 / 10	发料 6 件	−6	已有 ERP-T02，发送方回执丢失
RET-01 / 10	未耗用料退回 2 件	+2	尚无目标事务

期初与截止范围一起保存，禁止拿今天的实时库存与昨天的恢复快照直接相减。批次、库存状态、单位或所有权不同的记录，也不能为了让合计一致就合并。

恢复顺序沿依赖关系安排

演练先隔离外部写入，确认备份可读、恢复目标和身份权限，再恢复本样本所需的主数据、目标业务库和查询接口。随后检查来源日志、发送记录与消息位置，最后以受控批次开放重放。这是本样本的依赖顺序，实际系统应按运行架构和设备约束制定。

阶段	保留的证据	进入下一步的条件
控制入口	写入暂停记录、允许的只读操作	防止新旧写入混杂
恢复数据	备份身份、恢复日志、目标事务位置	能查询目标对象和来源键
固定范围	来源清单、目标快照、未决消息	明确本轮核对的截止边界
受控重放	同一业务键、执行结果、失败原因	每项动作能够查询与复核
重新开放	差异关闭、实物检查、责任人确认	满足业务方预定的恢复标准

备份“存在”和恢复“成功”都需要实际演练证据。恢复时间目标、可接受数据损失窗口及离线作业策略由企业确定，本篇不虚构通用的分钟数或可用性承诺。现场控制、安全联锁和业务平台的恢复也应分开验证。

恢复点与来源清单进入重放核对独立窗口查看 ↗

超时事务先查结果，再决定补执行

本例为每行动作保存稳定业务键：工厂、来源系统、事务类型、单据和行号。ERP 能按这个键查到目标记录，并以唯一约束或等效机制防止同一动作重复过账。载荷摘要也要比较；同一键出现不同数量时进入冲突处理，不能静默接受。

恢复后重送顺序为收料、发料、发料重发、退料。前两项查询命中原事务，第二次发料仍命中 ERP-T02，最后一项才新增 ERP-T03。网络确认丢失没有改变原有发料事实。

来源应有余额 = 100 + 20 − 6 + 2 = 116 件
ERP 恢复后余额 = 100 + 20 − 6 = 114 件
本轮新增过账 = 退料 +2 件
恢复后最终余额 = 114 + 2 = 116 件
4 次送达 → 3 个唯一动作 → 1 项新增过账

发送端可以在同一事务范围内保存业务变化和 Outbox 事件，再由工作进程发送。Microsoft 的示例明确介绍了这一原子范围；Cosmos DB 的具体实现还有逻辑分区限制。它支持可靠发布设计，不能替代目标 ERP 的幂等执行和恢复验证。Transactional Outbox 示例

Kafka 的设计文档也区分了系统内事务与外部目标的协作。消费位置提交成功，不能独立证明 ERP 账目已更新。Kafka 消息交付语义提供机制背景；这里的业务键和库存规则由样本自行定义。

如果目标系统不支持按来源键查询，也无法阻止重复写入，应暂停自动补执行，建立人工核实队列。若恢复时业务库与去重记录落在不同位置，需要重新核对二者；一个“已经处理”标记不能压过实际目标事务缺失的证据。

差异清单需要覆盖双向记录

只从来源向目标查找，容易漏掉目标多出的动作。本例同时从 ERP-T01 至 ERP-T03 回查来源，要求每行能映射到三项授权动作之一。接口重试日志保留送达次数，但不计入库存事务数。

检查	本样本验收结果	无法满足时的处理
来源覆盖	三项动作均有目标事务	缺项保持未决并补执行或说明
目标反查	三项目标均有来源	多项进入来源调查或授权纠错
数量与单位	+20、−6、+2，单位均为件	比较字段与转换依据
余额	双方 116 件	继续核对期初、范围与库存维度
执行重复	四次送达只对应三个动作	查询重复目标并走纠错流程
现场状态	另有实物及离线作业核查	逻辑账相等仍不能关闭现场差异

恢复期间纸面发料、移动端离线确认或其他旁路动作要登记到同一截止范围。找不到出处的 2 件差额不能通过一笔无依据调整自动消掉。授权调整也应保留原因、原始差异、审批和目标事务。

业务对账怎样形成重新开放依据独立窗口查看 ↗

把演练资料留下来复算

恢复演练 JSON保留期初、来源事务、恢复后目标、送达顺序和预期结果；样本校验程序核对重复投递、金额以外的数量守恒和目标反查。程序只运行本地教学数据，不连接数据库。

依据	支持的内容	适用边界
PostgreSQL 17 官方文档	备份、WAL、恢复目标与时间线	限于对应数据库机制
Microsoft Outbox 示例	业务变化与待发送事件共同提交	具体事务和分区约束需另核对
Kafka 3.2 设计文档	消息交付语义及外部系统协作边界	不证明 ERP 具有幂等接口
本篇 JSON 与校验程序	116 件余额与三个动作的复算	模拟输入，非灾备实测报告

上述网页于 2026-10-15 核对。上线演练还需记录真实版本、日志位置、耗时、失败注入方式和责任人签署；本篇样本可以作为验收表的起稿，不能填入实际演练结果一栏。