自动化恢复校验
把『恢复 + 校验』写成脚本并定期自动执行：把最新备份恢复到一个沙箱库，跑行数与抽样校验和比对，结果异常直接告警。它的价值在于把备份验证从依赖人的自觉，变成持续运行的系统行为。备份失败的告警容易做，而『备份文件存在但内容不可用』这类静默失效，只有恢复级别的自动校验能覆盖。
基本信息
| 运行环境 | 与生产隔离的沙箱主机或容器，禁止连回生产网络 |
|---|---|
| 触发方式 | systemd timer / cron / CI 定时任务，建议每周至少一次 |
| 校验对象 | 对象存在性、关键表行数、抽样校验和、应用冒烟查询 |
| 结果去向 | 监控与告警系统，而不是只写本地日志 |
典型使用场景
- 核心数据库备份的周级自动验活，提前发现备份损坏或库表缺失
- 备份软件更换或参数调整后的回归验证
- 文件服务器备份：抽样比对文件数与校验和，发现大量缺失
- 云上快照：定期用快照建卷挂载，确认文件系统可读
- 为季度演练兜底：平时自动校验，演练时专注端到端切换
校验脚本骨架
校验脚本骨架
#!/usr/bin/env bash
set -euo pipefail # 任何一步失败立即退出
BACKUP=/backup/appdb/latest.dump
pg_restore -d appdb_verify --clean --if-exists "$BACKUP" # 恢复到沙箱库
# 1) 关键表行数
psql -d appdb_verify -Atc "SELECT count(*) FROM orders" > /tmp/orders.cnt
# 2) 抽样校验和：对稳定字段做聚合，避免全量开销
psql -d appdb_verify -Atc "SELECT md5(string_agg(id::text, ',' ORDER BY id)) FROM orders WHERE id % 1000 = 0" > /tmp/orders.md5
# 3) 与上一周期基线比对，不一致则告警
diff -q /tmp/orders.md5 /baseline/orders.md5 || \
echo "ALERT: 校验和不一致" | mail -s "backup verify failed" ops@example.com校验深度对照
| 深度 | 手段 | 能发现的问题 |
|---|---|---|
| 1 文件级 | sha256sum -c | 归档传输损坏、截断 |
| 2 结构级 | 恢复后比对表与索引数量 | 对象缺失、权限脚本未执行 |
| 3 数据级 | 关键表行数与抽样校验和 | 数据大量缺失或错乱 |
| 4 业务级 | 冒烟查询与口径对账 | 行数正常但金额、状态等逻辑错误 |
基线不要硬编码数字：数据每天增长，写死的期望值会天天误报，最终被当噪音忽略。正确做法是把上一周期的正常结果留作基线做相对比对。
沙箱必须与生产网络隔离：恢复实例带着生产数据却对外可达，或校验脚本误连生产库执行 clean，都会造成真实数据损失。