XtraBackup热备需满足三个硬性前提：MySQL使用InnoDB/XtraDB引擎、启用独立表空间（innodb_file_per_table=ON）、备份用户具备最小必要权限，缺一则报错或降级为加锁备份。
能实现，但必须满足三个硬性前提：MySQL用的是InnoDB/XtraDB引擎、数据文件启用独立表空间（innodb_file_per_table=ON）、备份用户具备最小必要权限。缺一不可，否则不是报错就是降级为加锁备份。
确认 MySQL 是否支持 XtraBackup 热备
不是所有 MySQL 配置都默认兼容。重点检查三项：
-
SHOW VARIABLES LIKE 'innodb_file_per_table';—— 必须为ON，否则无法做单表恢复，且部分增量逻辑失效 -
SHOW VARIABLES LIKE 'innodb_log_file_size';—— 备份过程会读取 redo log，太小（如 48MB）容易被覆盖导致备份不一致 -
SELECT ENGINE, TABLE_NAME FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'your_db';—— 若存在MyISAM表，XtraBackup 会在备份时对这些表加READ LOCK，业务写入会阻塞
创建最小权限数据库用户而非直接用 root
用 root 备份看似省事，但 prepare 或 restore 阶段可能因权限缺失失败，且安全风险高。推荐建专用用户：
- 执行
CREATE USER 'bkpuser'@'localhost' IDENTIFIED BY 'strong_pass_2026'; - 授予权限：
GRANT BACKUP_ADMIN, PROCESS, RELOAD, LOCK TABLES, REPLICATION CLIENT ON *.* TO 'bkpuser'@'localhost'; - 注意：
LOCK TABLES权限仅用于 MyISAM 表临时加锁，InnoDB 表全程无锁；REPLICATION CLIENT是为了获取 binlog 位置，方便后续 PITR - 不要漏掉
FLUSH PRIVILEGES;，否则权限不生效
xtrabackup 命令中 --prepare 的时机和参数不能错
很多人在增量备份后直接拿 --prepare 对基础备份目录操作，结果报 Invalid backup: cannot find xtrabackup_checkpoints 或 LSN 不连续 —— 这是因为 prepare 必须按顺序“合并”增量，且基础备份本身要先 prepare 一次：
- 全量备份后先运行：
xtrabackup --prepare --target-dir=/backup/full（此时只是 rollback 未提交事务，不 redo） - 第一次增量应用：
xtrabackup --prepare --target-dir=/backup/full --incremental-dir=/backup/inc1 - 第二次增量必须基于上一步已合并的结果：
xtrabackup --prepare --target-dir=/backup/full --incremental-dir=/backup/inc2 - 最终得到的
/backup/full才是可恢复的一致状态；中间任何一步中断，就得从头来
备份输出目录权限和磁盘空间常被忽略
备份过程本身不校验目标路径权限，但 prepare 和 restore 阶段会因权限不足静默失败或报 Permission denied on xtrabackup_logfile 类错误：
- 确保运行
xtrabackup的 OS 用户（如mysql或root）对备份目录有rwx权限，且 SELinux 处于 permissive 模式（getenforce返回Permissive） - 磁盘剩余空间至少是数据目录大小的 1.5 倍：因为备份期间 redo log 持续追加到
xtrabackup_logfile，该文件可能涨到几个 GB - 别把备份目录放在
/tmp下——某些发行版会定期清理，导致xtrabackup_logfile被删，prepare 时直接崩溃
LSN 对齐和 redo replay 是整个机制的隐性核心，它不暴露在命令行里，但一旦源库 LSN 跳变（比如误删了 ib_logfile、或人为 reset master）、或备份过程中磁盘 IO 延迟突增，就可能导致 prepare 后数据页仍不一致——这种问题不会报错，只会在恢复后查出主键冲突或索引损坏。
