买家查支付失败，可能是 RPC 入口超时、执行端落后、共识端无新 finalized 检查点，也可能是订单索引比网络慢。区块链（35）：Fabric 的背书、排序与有效提交是三个阶段提醒“交易在块里”和“有效提交”不同；生产运维必须监控各层高度、状态、拒绝率和恢复延迟，而不是只测 HTTP 是否返回 200。

flowchart LR
  U[API/钱包] --> R[RPC: 身份/限流/网络边界]
  R --> EL[执行客户端: 头/状态/回执]
  EL --> CL[共识客户端: 同步与终局]
  EL --> DB[索引与订单数据库]
  EL --> BK[快照/备份/重放]
  CL --> OBS[监控: 最终性停滞]
  DB --> OBS

备份不是复制一个运行中的目录就宣称可恢复；要记录网络、genesis、fork 配置、版本、可信检查点、数据完整性与密钥隔离，并在隔离环境重启重放。区块体裁剪与交易历史索引要分开备份；钱包密钥恢复有独立权限边界。RPC 对公网提供写接口会引入批量滥用与凭据泄漏，验证者签名密钥更不应与普通查询服务同权限。升级时先核对与网络 fork 的兼容性、落后节点同步策略，再安排读写切换与回退。

恢复测试要故意离线一段时间

单独看 RPC 200、EL 已同步高度或“最近有日志”都可能误诊：EL 状态更新滞后，CL 的 finalized 检查点未前进，以及链下索引游标落后，会给出三种不同的订单风险。最小观测面应按同一网络记录：EL/CL 的头与终局进度、RPC 错误/延迟、待处理交易和旧 nonce、索引所在块哈希、回填窗口、最终业务对账差额。原始时间戳须同源或说明时钟偏差，否则不能把不同进程的毫秒值直接做因果排序。

恢复演练可在隔离副本故意把订单索引停在高度 h，保留其对应块哈希，再让测试网络继续生成若干块与一次重组。恢复者先从受信网络起点与客户端版本验证链，再从共同祖先回填派生记录，直到订单表与当前资产责任一致；从最新高度直接订阅会永久漏掉 h 之后的事件。备份须包括业务数据库快照与 WAL/游标、客户端配置、历史数据保留位置和可追溯的软件 SHA；签名密钥要单独隔离，不应混入公开备份。当前环境没有真实节点，此处只定义可检验的恢复判据，不能标为已完成演练。

练习一：eth_getTransactionReceipt 查询正常而 finalized 检查点长时间不变，订单能按“最终完成”告知用户吗？答案：不能，要单列执行观察与共识进展。练习二：从旧快照恢复索引后直接从最新高度接订阅，可能丢什么？答案：快照游标到最新高度之间的历史；先回填并验证块哈希。真实节点重启/备份/恢复/升级演练 NOT_RUN。

可迁移原则：把读入口、状态权威与恢复数据分别设计和报警。参考：Ethereum 节点和客户端、Bitcoin Core 文档（版本/SHA 未冻结）；导航：区块链（35）：Fabric 的背书、排序与有效提交是三个阶段 · 36 · 区块链（37）：比较吞吐之前先定义哪一种完成。