备份后必须立即验证 mysqlcheck
或还原测试
只执行
mysqldump或
mysqlpump不代表备份可用。常见错误是备份脚本跑完就认为万事大吉，结果恢复时才发现 SQL 文件末尾被截断、字符集不一致导致乱码、或
DEFINER权限语句引发导入失败。
实操建议：
每次备份完成后，用head -n 20和
tail -n 20检查文件头尾是否含完整
CREATE DATABASE和
UNLOCK TABLES（对
mysqldump） 对关键库，每周至少一次在测试环境执行完整还原：
mysql -u root -p ，再用 <code>mysqlcheck --all-databases --check验证表结构与行数 若使用
Percona XtraBackup，务必运行
xtrabackup --prepare后再测还原，跳过该步的“备份”无法启动实例
mysqldump
必须加 --single-transaction
和 --routines
缺省参数下导出的备份，在事务活跃或含存储过程/函数的库上大概率不可用。例如未加
--single-transaction时，
MyISAM表会锁表，而
InnoDB表可能因长事务导致快照不一致；不加
--routines则存储过程丢失，应用调用直接报错
PROCEDURE not found。
实操建议：
强制包含：mysqldump --single-transaction --routines --triggers --events --set-gtid-purged=OFF -u user -p db_name > backup.sql避免用
--all-databases直接备份，它会混入
mysql系统库，恢复时权限表冲突极易导致主从断裂 若库中存在
JSON字段或 8.0+ 的
DESCRIBE兼容语法，加上
--skip-column-statistics防止低版本 MySQL 导入失败
二进制日志（binlog）不是备份，但它是 RPO 达标的唯一手段
纯
mysqldump备份只能恢复到某一时点，中间所有 DML 都丢失。没有开启并保留 binlog，就谈不上“灾难恢复可用”——比如误删表后，你只有备份文件，却无法回滚到删除前一秒。
实操建议：
确认my.cnf中已启用：
log-bin=mysql-bin、
binlog-format=ROW、
expire_logs_days=7（至少保留一周） 每日全量备份 + 每小时截取 binlog：用
mysqlbinlog --start-datetime="2024-04-01 09:00:00" mysql-bin.000001 > incremental.sql恢复流程必须是两步：先还原最近全备，再按顺序重放 binlog —— 漏掉任意一个 binlog 文件，数据就永久不一致
备份文件权限和存储路径容易被忽略
备份文件生成在
/tmp或
/root下，看似能写入，但恢复时 MySQL 进程（通常是
mysql用户）无权读取，直接报错
File '/tmp/backup.sql' not found；或者备份存到 NFS 存储但没配
noac选项，导致
stat()缓存引发时间戳校验失败。
实操建议：
备份命令统一用sudo -u mysql mysqldump ...生成文件，确保属主为
mysql:mysql存储路径避开
/tmp、
/root、
/home，固定用
/backup/mysql/并设
chmod 750若走网络存储，挂载时加
nfsvers=4.1,hard,intr,noac，否则
cp或
mysql读取时可能静默失败 备份可靠性的核心不在工具多强大，而在每一步是否可验证、可重现、可审计。最常失效的环节，往往不是 dump 命令本身，而是权限、路径、binlog 切换点、以及那个没人愿意花十分钟去还原测试的“最后一步”。
