备份与恢复演练必须验证数据可读、一致、可用，而非仅跑通脚本；需检查文件完整性、权限路径、配置同步、日志连续性及隔离恢复，并执行业务级SQL验证。
备份与恢复演练不是“跑通脚本”就完事，而是要验证数据可读、一致、可用。很多故障不是在真正灾难时才暴露，而是在演练阶段就卡住——比如备份文件打不开、恢复后服务起不来、时间点恢复失败。关键在于提前识别风险点，并用最小代价验证每个环节。
备份文件本身不可用
这是最基础也最容易被忽略的一环。备份文件存在 ≠ 备份有效。
- 检查文件完整性：用
md5sum或sha256sum比对备份前后的校验值；对tar包可快速验证：tar -tzf backup.tar.gz > /dev/null（无报错说明归档结构正常） - 确认压缩/加密未出错：若用了
gzip或openssl，留意命令退出码（$?），非0即失败；避免管道中错误被吞掉，例如：mysqldump db | gzip > b.sql.gz应改为mysqldump db | gzip -c > b.sql.gz && [ $? -eq 0 ] || echo "dump failed" - 警惕“空备份”：某些定时任务因权限不足、磁盘满、路径写错，生成的是零字节文件。加一句
[ -s backup.tar.gz ] || echo "backup is empty!"能早发现问题
恢复后服务无法启动
数据库或应用恢复后连不上、报错“table doesn’t exist”或“permission denied”，往往不是备份问题，而是上下文丢失。
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
- 路径与权限不匹配：恢复到新机器时，原备份中的绝对路径（如
/data/mysql）可能不存在，或属主不是mysql用户。恢复后务必执行：chown -R mysql:mysql /var/lib/mysql+chmod -R 750 /var/lib/mysql - 配置文件未同步：只恢复了数据目录，但
my.cnf里datadir指向旧路径，或innodb_log_file_size参数与备份时不一致，会导致MySQL拒绝启动。建议把配置文件也纳入版本化备份 - SELinux或AppArmor拦截：CentOS/RHEL上恢复后Apache打不开日志、PostgreSQL连不上socket，先看
ausearch -m avc -ts recent | audit2why或临时设为permissive模式验证是否策略导致
时间点恢复（PITR）失败
基于binlog或WAL的增量恢复常卡在“找不到日志”或“应用中断”。核心是日志链不能断。
- 确认基础备份与日志的时间连续性：用
mysqlbinlog --base64-output=decode-rows -v binlog.000001 | head -20查看起始GTID或position；再用SHOW MASTER STATUS查当前日志位置，确保中间无跳跃或删除 - 日志被自动清理：MySQL默认
expire_logs_days=0不清理，但很多生产环境设为7天。演练前运行SHOW BINARY LOGS，确认所需binlog仍在磁盘上；PostgreSQL需检查archive_command是否真把WAL存到了目标目录且没被误删 - 时区或时间戳混淆：用
mysqlbinlog --start-datetime="2026-10-05 14:30:00"恢复时，该时间是MySQL服务器本地时区，不是UTC或你的终端时区。统一用--start-position更可靠
演练流程本身不可重复
一次成功的演练不该依赖“当时刚好没其他写入”。真实灾难不会挑时机。
- 避免在业务高峰期做全量恢复测试：否则可能触发锁表、连接数爆满、监控误告警。应在低峰期+明确标记下进行，例如加注释：
# PITR test for order_db, started at $(date) - 恢复目标隔离：绝不直接恢复到生产库。必须使用独立实例（哪怕只是
docker run -d -p 3307:3306 mysql:8），并修改应用连接串指向测试端口 - 缺少验证步骤：恢复完成后，不能只看“service mysql status”是active。要跑一条业务级SQL，比如
SELECT COUNT(*) FROM user_orders WHERE created_at > '2026-10-05'，确认数据时效性和逻辑正确性
