不能直接救命，但决定了你能不能“活下来重来”，关键在恢复速度和数据一致性；mysqldump需加--single-transaction、binlog须启用row格式并保留完整、权限与备份校验缺一不可。

SQL注入发生后，备份真能救命吗

不能直接救命，但决定了你能不能“活下来重来”。备份只是容灾链条里最基础的一环，关键在「恢复速度」和「数据一致性」。很多团队以为定期 mysqldump 就算完成任务，结果注入删库后发现：备份是3天前的、binlog没开、权限配置导致无法还原单表。

• mysqldump 默认不包含 --single-transaction 时，可能导出不一致快照（尤其对 InnoDB 大表）
• 只备份 .sql 文件却不保留 binlog，意味着无法还原注入发生到备份之间的所有变更
• 备份用户若只有 SELECT 权限，遭遇注入后即使有备份，也未必能执行 CREATE DATABASE 或 DROP TABLE 恢复操作

用 mysqlbinlog 做时间点恢复必须满足的三个条件

不是开了 binlog 就能回退到注入前一秒。漏掉任意一个条件，mysqlbinlog 就会变成“只能看不能用”的日志文件。

• MySQL 启动时必须启用 log_bin，且 binlog_format = ROW（STATEMENT 格式下，WHERE 1=1 类注入语句无法精确定位被改行）
• 备份必须带 --master-data=2 参数，否则你不知道该从哪个 binlog 文件和位置开始解析
• 注入发生前后，binlog 文件不能被 PURGE BINARY LOGS 清掉——建议用 expire_logs_days = 7 而非依赖手动清理

容灾演练常被跳过的致命步骤：模拟真实攻击路径还原

多数演练只做“停库→还原备份→启动”，却从不验证：注入语句是否已写入 binlog？被删的表结构能否从 information_schema 恢复？权限表 mysql.user 是否也被篡改？

• 演练时务必用真实应用账号连接数据库，执行一条可控的 UPDATE users SET name='x' WHERE id=1 OR 1=1 模拟注入效果
• 还原后立刻检查 SELECT COUNT(*) FROM users 和 SHOW CREATE TABLE users，确认行数与结构未被破坏
• 如果应用使用了 DEFINER 存储过程或视图，需额外验证 mysql.proc 和 mysql.views 表是否完整

备份策略要匹配注入风险等级：小项目别硬套金融级方案

一个只有 20 张表、日增 1MB 的后台系统，每天全量 + 每小时 binlog 备份，反而容易因磁盘满导致备份静默失败。重点不在“多”，而在“可验证”。

• 用 md5sum 校验备份文件完整性（mysqldump 出错时可能生成空文件）
• 每周至少一次「备份解压 + mysql -e "SHOW TABLES"」，确认能读取而非仅存档
• 避免把备份存到和数据库同块磁盘——注入后攻击者常顺手 rm -rf /data/backup

真正卡住恢复的，往往不是技术多难，而是没人记得上周的备份脚本里 --ignore-table 排除了 logs 表，而审计日志恰恰记录了谁执行了注入语句。