必须用xtrabackup而非mysqldump，因其直接拷贝ibd文件并实时捕获redo日志，不走SQL层，避免undo log膨胀、DDL不一致及慢恢复；而mysqldump--single-transaction仅是逻辑准热备，长事务易引发死锁且无法保证DDL期间一致性。
Percona XtraBackup 是唯一能真正实现 InnoDB 物理层热备份的开源工具，其他方案（如 mysqldump --single-transaction）只是逻辑层“准热备”，在大库或高写入场景下容易拖慢事务、撑爆 undo log。
为什么必须用 xtrabackup 而不是 mysqldump？
因为 mysqldump --single-transaction 本质是启动一个长事务读取全库快照，它不锁表但会：
• 持续占用 undo log 空间，写入压力大时可能触发 ERROR 1205 (HY000): Deadlock found when trying to get lock
• 无法备份表结构变更（DDL）期间的数据状态，ALTER TABLE 正在执行时备份可能不一致
• 导出文件是 SQL 文本，恢复速度慢，TB 级数据往往要数小时
而 xtrabackup 直接拷贝 ibd 文件 + 实时捕获 redo 日志，全程不走 SQL 层，对业务 QPS 几乎无影响。
xtrabackup 全量备份必须做的三件事
漏掉任意一步，备份就无法恢复：
• --backup 后必须立即执行 --prepare —— 否则数据页处于“中间态”，ibdata1 和 .ibd 文件未对齐，强行恢复会报 InnoDB: Tablespace is missing for table
• --target-dir 目录必须为空且有写权限，xtrabackup 不会自动创建父目录
• 备份用户需具备 RELOAD、PROCESS、REPLICATION CLIENT 权限，仅 SELECT 不够
增量备份怎么接上全量？关键看 --incremental-basedir
增量不是独立存在，它依赖前一次 prepare 过的全量目录：
• 增量命令里 --incremental-basedir 必须指向已 --prepare 的全量目录（不是原始备份目录）
• 第二次增量要基于第一次增量的 --prepare 结果，不能跳级
• 所有增量备份完成后，需按顺序 --prepare：先全量加 --apply-log-only，再逐个增量加 --apply-log-only，最后全量不加该参数完成最终一致性
恢复时最容易被忽略的权限和路径问题
即使 --copy-back 成功，MySQL 启动失败大概率是这两点：
• 数据目录属主不是 mysql 用户，chown -R mysql:mysql /var/lib/mysql 必须执行
• my.cnf 中 datadir 路径和 --copy-back 目标目录不一致，比如备份时指定 --target-dir=/backup/full，但恢复时 datadir=/var/lib/mysql，却忘了清空该目录再 copy
• innodb_file_per_table=ON 必须启用，否则 xtrabackup 无法单独处理每个表空间
