xtrabackup是唯一真正实现innodb物理层热备份的工具，因其直接拷贝.ibd文件并实时捕获redo日志，不走sql层；而mysqldump--single-transaction仅启动长事务读取快照，会占用undo log、无法保证ddl一致性、恢复慢且myisam仍被锁。
xtrabackup 是唯一能真正实现 InnoDB 物理层热备份的工具，mysqldump --single-transaction 只是逻辑层“准热备”，大库或高写入场景下极易出问题。
为什么不能只用 mysqldump --single-transaction
它本质是启动一个长事务读取全库快照，不锁表但会：
• 持续占用 undo log 空间，写入压力大时可能触发 ERROR 1205 (HY000): Deadlock found when trying to get lock
• 无法保证 ALTER TABLE 正在执行时的数据一致性
• 导出的是 SQL 文本，TB 级恢复常需数小时
• MyISAM 表仍会被锁（哪怕加了 --single-transaction）
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 无法单独处理每个表空间
