备份前必须确认的3个前提条件：①MySQL启用innodb_file_per_table=ON；②运行用户对数据目录有读权限、对备份路径有写权限；③MySQL开启binlog且推荐binlog_format=ROW。
备份前必须确认的 3 个前提条件
不是所有 MySQL 实例都能直接用 xtrabackup 备份。它依赖底层文件系统和 MySQL 配置，漏掉任一条件都会在 backup 阶段报错或产生不一致备份。
- MySQL 必须启用
innodb_file_per_table = ON（5.6+ 默认开启，但旧实例常关闭）；否则xtrabackup无法单独处理单表空间，备份会失败或跳过部分库 - 运行用户需对 MySQL 数据目录（如
/var/lib/mysql）有读权限，且对备份目标路径有写权限——常见错误是用sudo -u mysql启动但目标路径属主为 root，导致写入失败 - MySQL 必须开启 binlog（
log_bin），且推荐开启binlog_format = ROW；否则即使备份成功，也无法做基于时间点恢复（PITR）
全量备份命令的实际写法与关键参数
官方文档里 xtrabackup --backup 看似简单，但生产环境几乎从不用裸命令。以下是最小可用、带容错的写法：
xtrabackup \ --user=root \ --password=xxx \ --backup \ --target-dir=/backup/full_$(date +%F_%H%M%S) \ --parallel=4 \ --compact \ --throttle=200
说明：--parallel 加速 I/O，但值不宜超过 CPU 核数；--compact 跳过 BLOB/TEXT 页（减小体积，但后续 prepare 时需加 --rebuild-indexes）；--throttle 控制每秒 IO 次数，防止拖慢线上业务。
- 不要省略
--user和--password：用配置文件（如~/.my.cnf）虽方便，但若文件权限不对（比如被其他用户可读），xtrabackup会直接拒绝启动 -
--target-dir必须是空目录，且不能是相对路径——xtrabackup不自动创建父目录，也禁止写入非空目录，否则报错Target dir exists and is not empty - 避免使用
--stream=tar直接压缩：虽然节省磁盘，但一旦网络中断或管道阻塞，整个备份就损坏，无重试机制
备份后必须执行 prepare，否则备份不可用
刚备份完的目录是「未一致性状态」：InnoDB redo 日志尚未回放，事务可能未提交或已回滚。不 prepare 就直接恢复，MySQL 启动时会崩溃或拒绝加载数据。
- 全量备份后的标准操作是：
xtrabackup --prepare --target-dir=/backup/full_2024-06-15_143000 - 如果用了
--compact，prepare 时必须加--rebuild-indexes，否则表能打开但查询会报Index column ... is of type TEXT/BLOB - prepare 过程不可中断，且耗时可能接近备份本身——它本质是重放 redo + 回滚未提交事务，CPU 和磁盘压力都高
- 不要用
mysqlcheck或mysqld --innodb-force-recovery验证备份：它们无法替代prepare，且可能污染备份目录
恢复到新实例时最容易忽略的权限与路径细节
把备份拷到新机器上只是第一步。MySQL 启动失败往往不是因为数据坏了，而是文件归属或路径没对齐。
- 恢复前清空目标数据目录（如
/var/lib/mysql），并确保其属主为mysql:mysql；xtrabackup --copy-back不改文件属主，只复制内容 -
--copy-back的--target-dir必须指向「已 prepare 过」的备份目录，否则报错ibdata1 not found或magic number mismatch - 恢复后首次启动前，检查
my.cnf中的datadir是否与实际路径一致——很多运维习惯性保留原配置，结果 MySQL 去旧路径找文件 - 如果原实例启用了
innodb_page_size=64K或innodb_log_file_size非默认值，新实例的配置必须完全一致，否则启动直接 abort
备份不是“跑完命令就完事”，prepare 和恢复两个环节的校验动作缺一不可。尤其跨版本恢复（比如 5.7 备份恢复到 8.0），务必先查 xtrabackup 版本兼容矩阵——低版本工具备份的 5.7 实例，在 8.0 上 prepare 可能静默失败。
