备份前必须确认的 4 个状态
Percona XtraBackup 不是“拿来就跑”的工具，它对 MySQL 实例状态敏感。备份失败往往不是命令写错，而是环境没对齐。
mysqld进程必须正在运行，且
socket文件可访问（
--socket=/var/lib/mysql/mysql.sock要匹配实际路径） MySQL 用户需有
RELOAD、
LOCK TABLES、
REPLICATION CLIENT权限，仅
SELECT不够 InnoDB 表空间不能启用
innodb_file_per_table=OFF（XtraBackup 8.0+ 已不支持全局表空间备份） 若启用了
innodb_encryption或 TDE，必须提前配置
keyring_file_data并确保备份时 keyring 插件已加载
xtrabackup --backup 命令的关键参数取舍
看似简单的备份命令，参数组合直接影响恢复可用性。最常被忽略的是
--target-dir和
--no-timestamp的配合问题。
--target-dir必须指定为**空目录**；若目录存在且非空，
xtrabackup默认拒绝写入（除非加
--force-non-empty-directories，但不推荐）
--no-timestamp要和
--target-dir同时使用，否则会在目标路径下自动生成时间戳子目录，导致后续
--prepare找不到预期结构
--parallel=4可提升备份速度，但并发数不宜超过物理 CPU 核心数；过高反而因 I/O 争抢拖慢整体耗时 不加
--stream=tar时，备份是本地文件目录；加了就必须配合
--compress和管道重定向，例如：
xtrabackup --backup --stream=tar ./backup/ | gzip > backup.tar.gz
prepare 阶段为什么总报 “Log sequence number mismatch”
这是恢复链断裂的典型信号——
--prepare本质是回放 redo log 到数据文件，若日志不连续或被截断，就会失败。 单次完整备份后，必须执行
xtrabackup --prepare才能用于恢复；只备份不 prepare 的数据目录无法启动 MySQL 若做了增量备份，prepare 顺序必须是：先 prepare 全备（加
--apply-log-only），再按时间顺序依次 prepare 每个增量包（也都加
--apply-log-only），最后对最后一个增量包 **去掉**
--apply-log-only执行最终 prepare 误删或覆盖了
xtrabackup_logfile（即使备份已完成），会导致 prepare 报错；该文件必须和备份目录一起保留
恢复到新实例时 /etc/my.cnf 的关键适配项
直接把备份数据拷过去改个
datadir就启动？大概率失败。MySQL 启动时会校验元数据一致性。
innodb_data_home_dir和
innodb_data_file_path必须与原备份环境一致；若原环境用默认值（如
ibdata1:12M:autoextend），新实例也别改
server_id必须修改，否则在主从场景下可能引发 GTID 冲突或复制中断 若原库启用了
innodb_page_size=64K，新实例的
my.cnf中必须显式声明，否则启动时报
page size mismatch恢复后首次启动建议加
--skip-grant-tables和
--skip-networking，验证数据可读后再开放连接
备份本身不难，难的是让 prepare 出来的数据能真正被 mysqld 认作“合法的 InnoDB 文件”。每一步的中间产物（尤其是
xtrabackup_checkpoints和
xtrabackup_info）都得留着，它们才是恢复时唯一可信的时间戳和状态凭证。
