备份必须验证才可用：需检查SQL文件完整性、定期还原测试、避免--all-databases、适配JSON/8.0语法、启用并保留binlog、规范权限与存储路径。
备份后必须立即验证 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读取时可能静默失败
