恢复完成后需逐层验证：先确认实例正常运行并能连接，检查日志无错误；再核对数据库对象数量与结构一致性，确保表、索引、约束完整；接着抽样验证核心表数据内容准确性，比对行数和关键记录；然后确认事务一致性，检查是否退出恢复模式及WAL应用到位；最后进行业务层测试，验证应用读写、函数调用及权限设置正确，确保整体可用。
数据恢复的有效性验证是 PostgreSQL 运维中的关键环节。恢复完成后，不能默认数据可用就代表完整准确。必须通过一系列检查手段确认恢复的数据与原始状态一致、结构完整、业务可读。以下是一套实用的 PostgreSQL 数据恢复校验策略。
1. 检查数据库基础状态
恢复后第一件事是确认实例是否正常运行，并能访问目标数据库。
- 使用 psql -h [host] -p [port] -U [user] -d [db] 尝试连接，确认能否登录
- 执行 SELECT version(); 验证实例正常响应
- 查看日志文件（如 pg_log 或 log_directory 中的日志），排查是否有启动错误或恢复中断记录
2. 核对对象数量与结构一致性
对比恢复库与源库的数据库对象，确保表、索引、视图等未缺失。
- 查询表数量：SELECT count(*) FROM pg_tables WHERE schemaname = 'public';
- 对比关键表是否存在：\dt schema.table_name 或查询 pg_class 和 pg_namespace
- 检查表结构：\d table_name 查看字段、类型、约束是否匹配
- 验证索引和主键是否存在
，特别是外键关系是否保留
，特别是外键关系是否保留3. 抽样验证数据内容准确性
仅结构存在还不够，必须确认数据内容正确。
- 选择几个核心业务表，执行 SELECT COUNT(*) 对比恢复前后行数（若原库仍可查）
- 抽取已知记录做精确比对，例如：SELECT * FROM users WHERE id = 1001; 看字段值是否一致
- 检查时间字段范围是否合理，比如订单表的最大/最小创建时间是否符合预期
- 查看是否有异常空值或截断数据
4. 验证事务一致性与WAL应用情况
如果是基于 PITR（时间点恢复）或从 WAL 归档恢复，需确认恢复截止点准确。
- 检查恢复完成后生成的 recovery.conf（或 PostgreSQL 12+ 的 standby.signal）是否被自动清除
- 查询 pg_is_in_recovery() 应返回 false，表示已退出恢复模式
- 查看 pg_wal 目录中 WAL 文件的应用情况，确认没有遗漏或跳过关键日志
- 若有备份时记录的 LSN 或时间戳，可通过 pg_stop_backup() 记录对比恢复位置
5. 业务层联动测试
数据库层面正常不代表应用可用，最终要由业务验证。
- 连接实际应用或脚本，尝试执行典型操作：读取用户信息、插入新记录、触发事务等
- 检查触发器、函数、存储过程能否正常调用
- 确认权限设置正确，角色和用户登录无误
- 若使用了复制或逻辑订阅，验证后续复制是否可继续
基本上就这些。一套完整的恢复验证不是一次查询就能完成的，而是从实例状态到对象结构，再到数据内容和业务可用性的逐层确认。定期演练恢复流程并固化校验脚本，能显著提升生产环境的容灾可靠性。不复杂但容易忽略。
