xtrabackup备份失败主因是前置条件未满足：mysql用户缺super/reload/process/replication client权限、innodb_log_file_size与实际日志文件大小不一致、--target-dir非空、caching_sha2_password认证不兼容；全量备份必须严格执行--backup→--prepare→--copy-back三步，增量备份须按lsn顺序prepare，恢复前需校验xtrabackup_checkpoints及版本兼容性。
Percona XtraBackup 是目前最可靠、生产环境验证最多的 MySQL 物理备份方案，但直接跑 xtrabackup --backup 很可能失败——不是命令错，而是权限、版本、目录状态或日志配置没对齐。
为什么 xtrabackup --backup 会报错或卡住
常见现象包括：Failed to connect to MySQL server、Cannot open /var/lib/mysql/ib_logfile0、备份中途退出且无明确错误、xtrabackup_checkpoints 文件缺失或 LSN 异常。根本原因往往不在命令本身，而在前置条件未满足：
- MySQL 用户缺少必要权限：
SUPER（用于FLUSH TABLES WITH READ LOCK）、RELOAD（FLUSH LOGS）、PROCESS（检查线程）、REPLICATION CLIENT（读取 binlog 位置） -
innodb_log_file_size配置值与磁盘上实际ib_logfile*文件大小不一致，XtraBackup 依赖该值解析 redo log -
--target-dir目录非空（XtraBackup 要求必须为空或不存在） - MySQL 使用了
caching_sha2_password插件但未配置兼容连接方式（如未启用--socket或未在~/.my.cnf中指定default-auth = mysql_native_password）
全量备份必须执行的三步不可跳过
物理备份不是“拷完文件就完事”，XtraBackup 的设计逻辑是模拟 InnoDB 崩溃恢复过程，因此以下三步顺序固定、缺一不可：
-
备份（
--backup）：在线拷贝数据文件 + 记录起始 LSN 和 binlog position，生成xtrabackup_checkpoints和xtrabackup_binlog_info -
准备（
--prepare）：重放 redo log（前滚），回滚未提交事务（后滚），使备份目录达到“可启动一致性状态”。这一步必须在恢复前完成，且不能跳过 —— 即便你只是想校验备份有效性，也得先--prepare再尝试启动一个临时实例 -
还原（
--copy-back）：仅在 MySQL 已停止、/var/lib/mysql已清空的前提下执行；它不校验目标目录权限，所以chown -R mysql:mysql /var/lib/mysql是硬性步骤，漏掉会导致启动失败并报Operating system error number 13
增量备份如何避免链式断裂
增量备份不是独立快照，而是基于某个基础备份（全量或前一次增量）的差量。一旦中间某次增量 prepare 失败或顺序错乱，整个链就失效。关键控制点：
- 首次增量必须指定
--incremental-basedir=/path/to/full_backup；后续增量则指向**上一次成功 prepare 后的增量目录**（不是原始备份目录） - 恢复时，prepare 顺序必须严格：先
--prepare --apply-log-only全量，再按时间顺序对每个增量重复该命令（最后一次增量除外），最后对最终增量执行不带--apply-log-only的--prepare - 每次 prepare 后检查
xtrabackup_checkpoints中的to_lsn是否与下一次增量的from_lsn匹配，这是链是否连通的唯一可信依据
恢复后 MySQL 启动失败的高频原因
即使 --copy-back 成功、权限也改了，MySQL 仍可能报 InnoDB: Database page corruption 或反复 crash。这时要立刻检查：
-
xtrabackup_checkpoints中的backup_type = full-prepared或incremental-prepared—— 如果仍是full-backuped，说明--prepare根本没执行成功 - MySQL 配置中
innodb_log_file_size是否与备份时一致；若不一致，启动时会拒绝加载 ib_logfile*，必须删掉并让 MySQL 重建（风险高，仅限测试环境） - 备份时用的 MySQL 版本与恢复目标版本是否兼容（例如用 XtraBackup 8.0 备份 MySQL 8.0.33，不能恢复到 8.0.28，LSN 解析可能出错）
真正容易被忽略的是：prepare 阶段不输出明显错误，但内部可能静默跳过某些表空间修复；务必用 innodb_force_recovery=1 启动一次，确认所有表都能被识别，否则上线后查不到数据才叫真麻烦。
