数据库进程启动、端口可连，只能说明还原进入了可检查阶段。恢复点可能错了，业务账号可能无权，序列可能落后，统计信息可能缺失，归档和备份任务也可能仍指向旧环境。此时直接开放流量，问题会从恢复现场扩散到业务。
KES 备份手册把还原、恢复与验证分开说明。交付前至少完成恢复点、对象数据、权限账号、统计性能、后台保护链和应用冒烟六项检查。
— 从数据库内部到外围任务，再到真实业务入口逐层放行。
一、恢复点是否正确
记录实际恢复停止时间、事务位置、备份集与时间线。核对目标点前的测试标记存在，目标点后的标记按预期不存在。不要只看命令里的目标参数，实际日志重放可能因缺档或时间线选择停在其他位置。
时区、服务器时间和业务日志时间要统一。由事故负责人确认该恢复点满足业务决定，而不是 DBA 单独凭感觉判断。
二、对象与数据是否完整
检查数据库、模式、表、索引、约束、视图、函数、过程、序列与表空间。对关键表核对行数、时间范围、主键样本、汇总值和关联关系。大表使用可复现的抽样与汇总，不以“能查一行”代替完整性。
序列当前值与业务数据最大值要匹配，防止新写入冲突。恢复涉及逻辑归档时，还要确认附属对象和依赖没有因选择性恢复遗漏。
三、权限与账号是否可用
用真实应用账号新建连接，执行允许的查询、写入和过程调用；再验证不允许的管理操作失败。管理员能操作不能代表权限恢复正确。
检查对象所有者、角色成员、默认权限、账号有效期和连接限制。异机恢复时，全局角色与表空间可能需要提前准备，所有授权失败都要在恢复日志中处理。
四、统计与核心 SQL 是否正常
逻辑恢复后按官方建议更新统计信息。选择核心查询检查执行计划、返回量与耗时，确认索引存在、统计估算合理。物理恢复也要观察缓存尚未预热带来的暂时变化，不要在刚启动一秒就下性能结论。
— 每一项检查都要留下查询、日志或业务验收记录。
五、后台保护链是否接上
确认归档、定时备份、远端复制、监控、审计和主备复制连接到当前实例。恢复后时间线或节点角色变化时，应尽快建立新基础备份，并受控保留旧链。
制造一段小量日志，验证它进入仓库；触发或等待一次备份任务，确认源实例标识正确。监控页面绿色但仍采集旧节点，是常见假象。
六、应用是否真正可用
应用团队使用真实入口完成登录、查询、写入、事务、核心流程和必要批处理。隔离演练环境要切断真实下游，避免恢复出的定时任务发送生产消息。
RTO 计时应到业务验收通过，不以数据库启动为结束。记录仍未开放的非核心功能与后续计划，不要用“基本可用”掩盖未知项。
分阶段放流量
先开放只读或少量实例，观察错误率、连接、锁、慢 SQL 和归档；再逐步恢复完整流量。任何异常有明确停止和回退条件。恢复后的第一小时加强监控，避免新写入让再次回退更复杂。
六项都通过后形成交付单：备份集与恢复点、日志、校验 SQL、权限测试、性能冒烟、后台任务状态和业务签字。还原完成只是工具阶段结束，业务安全接管才是恢复真正完成。
失败项要分级处理
恢复点错误、关键数据缺失、权限越界、归档未接续属于阻断项，不能带问题放流量。非核心统计未更新、低优先级报表暂未验证等问题，也要写明影响、临时措施和完成时间，不能口头留待后续。
每个失败项保存实际结果与期望结果，修复后只复测相关项还不够，还要回归它可能影响的前后步骤。例如重新授权后再次验证越权失败，重新建索引后再看统计与核心 SQL。
检查数据写入后的可持续性
放少量流量后观察新事务能提交、日志持续归档、序列继续增长、备库正常重放。恢复静态数据正确，却在首批写入时暴露只读状态、空间不足或日志路径错误，同样不能交付。
选择一条可回滚的业务记录完成新增、查询、修改和撤销，覆盖完整事务链。测试数据带明确标识，结束后按业务规则清理并保留审计证据。
做一次交接复述
由接管团队说明当前恢复点、尚存风险、下一备份时间和再次故障时的回退路径。若只能由恢复执行者解释，说明交付材料还不够清楚。恢复现场会结束，但后续值班必须能继续维护。
参考资料
- KES 官方备份还原手册：恢复验证
