核心是“可验证、可重复、不扰生产”，需明确恢复目标与范围、定义rto/rpo、分级数据优先级、分阶段演练、每步命令+验证标准+失败判断、嵌入备份验证与自动回滚机制、固化演练反馈闭环。
制定灾难恢复演练的数据恢复方案，核心是“可验证、可重复、不扰生产”。它不是写在纸上的应急预案，而是能真实跑通的一套操作路径。重点不在工具多炫酷，而在每一步是否可控、结果是否可衡量。
明确恢复目标与范围
先回答三个问题：要恢复什么？恢复到什么状态？业务能接受多久中断？
- 按数据类型分级：数据库文件（/var/lib/mysql）、网站代码（/var/www）、配置（/etc）、用户数据（/home）必须优先；/tmp、/var/cache 这类可重建的可排除
- 定义RTO（恢复时间目标）和RPO（恢复点目标）：例如“数据库丢失不超过5分钟数据，整站恢复不超30分钟”
- 区分演练类型：桌面推演（走流程）、模拟故障（关服务、删目录）、真实故障注入（如用dd破坏分区表）——从低风险开始逐步升级
设计可执行的恢复步骤
每一步都要有命令、预期输出、失败判断标准，禁用模糊描述。
- 备份介质验证：运行 tar -tzf /backup/www-$(date -d 'yesterday' +%Y%m%d).tar.gz | head -5 确认包存在且可读
- 数据库恢复：先停服务，再用 mysql -u root -p ，最后检查 mysql -e "SELECT COUNT(*) FROM user;" myapp 是否返回预期数值
- 文件系统级恢复：对ext4分区误删场景，用 extundelete /dev/sdb1 --restore-directory /var/www，恢复后校验文件数量与哈希值（sha256sum -c /backup/www.sha256）
嵌入验证与回滚机制
没有验证的恢复等于没恢复；没有回滚的演练等于制造新风险。
- 恢复后必做三件事：检查服务端口是否监听（ss -tlnp | grep :80）、访问首页抓HTTP状态码（curl -I http://localhost | head -1）、比对关键日志时间戳（tail -1 /var/log/nginx/access.log）
- 所有操作加前缀记录：script /tmp/recovery-$(date +%s).log，确保全程留痕
- 预设中止条件：如恢复超时15分钟、校验失败超3次、磁盘空间不足预警，立即终止并触发回滚脚本（如重新挂载只读快照）
固化演练反馈闭环
每次演练不是终点，而是下一轮优化的起点。
- 记录耗时瓶颈：是tar解压慢？MySQL导入卡在索引重建？还是权限修复漏了SELinux上下文？
- 更新备份策略：若发现某次演练因备份包损坏失败，就加入自动校验（gzip -t backup.tar.gz）到每日备份脚本
- 同步更新文档：把实际遇到的报错信息（如xfs_repair提示AG count mismatch）和对应解决命令，直接补进内部Wiki的FAQ章节
