冷备 vs 热备：停机是否可接受决定备份类型
如果业务能接受短暂停机（比如凌晨维护窗口），
mysqldump配合
FLUSH TABLES WITH READ LOCK是最简单可靠的冷备方式；一旦要求 7×24 运行，就必须用热备方案，否则锁表会导致应用写入失败甚至超时雪崩。 冷备适合小库（ 热备必须依赖物理备份工具，如
Percona XtraBackup或 MySQL 8.0+ 原生
mysqlbackup，它们通过拷贝 InnoDB redo log 和数据文件实现不锁表备份
mysqldump --single-transaction虽然不锁表，但只对 InnoDB 有效，且备份期间长事务会导致一致性视图膨胀，可能拖慢性能
mysqldump 参数组合直接影响备份可用性
默认的
mysqldump输出不具备完整恢复能力，漏掉
--routines、
--triggers、
--events会导致存储过程、触发器和事件丢失；而忽略
--set-gtid-purged=OFF在 GTID 模式下会直接报错无法导入。 基础可用组合：
mysqldump --single-transaction --routines --triggers --events --set-gtid-purged=OFF --databases db1 db2 > backup.sql大库务必加
--skip-lock-tables（配合
--single-transaction已隐含）并避免使用
--lock-all-tables导出后建议用
head -n 20 backup.sql检查开头是否有
SET @@SESSION.SQL_LOG_BIN= 0;—— 若有，恢复时可能意外跳过 binlog，导致主从不一致
Percona XtraBackup 备份失败常见原因
xtrabackup报错大多不是权限或路径问题，而是 MySQL 运行状态不匹配。比如
innodb_log_file_size变更后未重启 mysqld，备份会卡在
Copying ib_logfile0并最终超时；又或者
datadir下存在 symlink，XtraBackup 默认拒绝处理。 执行前先确认：
mysql -e "SHOW VARIABLES LIKE 'innodb_log_file_size';"与
ls -lh /var/lib/mysql/ib_logfile*大小一致 备份命令必须指定用户和 socket：
xtrabackup --user=root --socket=/var/run/mysqld/mysqld.sock --backup --target-dir=/backup/full_$(date +%F)不要直接 rsync 数据目录——InnoDB 文件非原子写入，硬拷贝大概率损坏，必须用
xtrabackup --prepare完成崩溃恢复模拟后才能恢复
备份保留策略必须绑定校验与恢复演练
存了 30 天备份却从没验证过能否还原，等于没备。真实故障时才发现
xbstream压缩包解不开、
mysqldump里混入了
/*!50718 ... */条件注释导致低版本 MySQL 导入失败，这类问题只能靠定期恢复测试暴露。 每周至少一次：用
mysql -e "CREATE DATABASE restore_test;"+
mysql restore_test 快速验证逻辑备份可读性每月一次：在隔离环境用
xtrabackup --copy-back恢复物理备份，并启动 mysqld 检查
SHOW ENGINE INNODB STATUS\G是否有 corruption 报告 所有备份文件需附带元信息：
echo "$(date) $(mysql -V) $(mysql -e 'SELECT @@version_comment;')" > backup_20240601.meta备份本身不难，难的是让每次备份都真正可恢复。最常被跳过的步骤是校验与演练，而不是选工具或写脚本。
