恢复旧数据库可能覆盖备份点之后的新订单、支付状态和库存变化，而支付平台上的真实交易不会因此消失。应先保全当前数据，明确业务时间窗，再制定核对与补回方案。不能直接还原后让客户重新付款，也不能假定备份插件会自动合并订单。
先记下最后可信时间点
确认备份生成时间、故障开始时间及恢复期间是否仍有业务写入。不同系统可能使用不同显示时区，核对时统一时间基准并保留原始记录。故障页面无法打开，不代表支付回调、后台队列或其他渠道已经完全停止更新，时间窗口需要证据支持。
保留当前数据再判断范围
即使当前站点有故障，也应在可行且获授权范围保全数据库与相关日志，防止旧备份覆盖唯一的新记录。记录订单、退款、库存与发货等依赖，不只统计订单数量。HPOS等实际存储方式会影响数据位置，不照搬从posts表复制订单的旧教程。
外部系统需要单独对账
支付、物流和ERP有各自的事实记录，网站回退不会撤销已收款或已发货状态。核对业务标识和状态转换，安排有权限人员处理差异，不能根据单一截图猜测资金。补回方案需避免重复扣款、通知或库存扣减，先在隔离副本验证方法。
恢复后分阶段开放业务
技术恢复完成后，先检查订单关联、客户信息与库存，再按业务确认结果恢复入口。记录哪些数据已核对、哪些需要人工跟进，不能因首页能访问就宣布商城全部恢复。对外说明应使用脱敏数量和范围，不展示客户订单明细或支付凭据。
关键区别
旧备份：保存过去状态；可能缺新订单。
支付平台：保存实际交易；不会随网站回退。
业务对账：核对多系统状态；不能只看订单数。
怎样确认处理到位
验收应能说明恢复点后的业务记录如何处理，并确认没有重复操作。技术可访问、数据已核对和业务获准恢复分别记录，不合并为一个完成状态。
容易误判的边界
不要直接拼接订单表或让客户重复支付。本文是恢复前的业务边界检查，不提供未经实际架构和交易核实的数据合并脚本，也不承诺零损失恢复。
