全量还原前必须先执行--prepare，因备份文件处于时间点不一致状态，需回放redo log以达成事务一致性；跳过会导致mysql启动报错。
全量还原前必须先执行 --prepare
备份文件直接拷贝回来不能直接用，因为备份过程中数据文件处于“时间点不一致”状态——InnoDB页可能被部分修改，redo log 里还存着未刷盘的变更。XtraBackup 的物理备份本质是“快照+日志”，恢复前必须把日志回放进去，让所有数据页达到事务一致性。这一步叫 --prepare，也叫“整理备份”。跳过它直接 --copy-back，MySQL 启动时大概率报错 InnoDB: Database page corruption 或卡在崩溃恢复阶段。
实操要点：
-
--prepare是只读操作，可离线执行，不依赖 MySQL 运行；建议在空闲机器上做，避免占用生产资源 - 全量备份只需一次
--prepare：例如备份目录是/xbk/full/2026-09-28_02-00-00/，命令为xtrabackup --prepare --target-dir=/xbk/full/2026-09-28_02-00-00/ - 如果用了增量备份，
--prepare要按顺序合并：先 prepare 全量，再用--redo-only依次 apply 增量，最后去掉--redo-only做最终 prepare（这点容易漏） - 执行完后检查输出末尾是否出现
completed OK!，并确认xtrabackup_binlog_info和xtrabackup_checkpoints文件存在且内容合理
--copy-back 必须满足路径与权限硬性条件
这步是真正把文件“放回去”，但 XtraBackup 不会自动创建目录、不处理属主、不校验磁盘空间。一旦出错，恢复就中断在半路，时间全白耗。
常见失败场景和应对：
- 目标
datadir非空：MySQL 启动会拒绝加载，必须提前rm -rf /var/lib/mysql/*（注意不是删整个目录，只清内容） - 属主错误：
--copy-back默认以当前用户身份写入，而 MySQL 进程需要mysql:mysql权限。执行后必须立刻chown -R mysql:mysql /var/lib/mysql - 路径不匹配：
--copy-back严格按my.cnf中datadir路径还原。若配置里写的是/data/mysql，但你误设成/var/lib/mysql，文件会拷到错地方，启动时报Can't open the mysql.plugin table - 磁盘空间不足：全量备份解压后大小 ≈ 原库占用空间。别只看备份包大小（可能压缩过），要预留至少 1.2 倍
datadir实际占用空间
MySQL 启动失败时优先查 error.log 里的三类关键线索
即使 --prepare 和 --copy-back 都成功，MySQL 仍可能起不来。这时候不要重跑流程，先盯住错误日志里这三处：
-
InnoDB: The log sequence number ... in ibdata1 is ...和InnoDB: The log sequence number ... in the system tablespace does not match：说明--prepare没做完或中途被杀，需重新 prepare -
Plugin 'sha256_password' is not loaded或Unknown plugin 'caching_sha2_password'：MySQL 8.0 默认认证插件变更，备份时用的是老版本，恢复后需手动在my.cnf加default_authentication_plugin=mysql_native_password（临时兼容） -
Can't find file: './mysql/plugin.frm'或类似系统表缺失：通常是--copy-back拷漏了mysql库下的文件，检查备份目录里是否有完整mysql/子目录，特别是ibdata1和ib_logfile*是否一并拷过来了
恢复速度瓶颈往往不在 XtraBackup 本身
从备份目录拷完文件到 MySQL 可服务，真正耗时的环节常被忽略：
- SSD 与 HDD 差异巨大：同一份 400GB 备份，NVMe SSD 上
--copy-back可能 8 分钟，SATA HDD 上可能 40 分钟以上。灾难恢复预案里必须明确目标机磁盘类型 -
innodb_buffer_pool_size设置过小会导致启动时加载慢：恢复后首次启动，InnoDB 要预热 buffer pool，若配置仅 128MB，而数据有 300GB，会反复换页，拖慢启动达数倍 - 没关 SELinux 或 AppArmor：某些发行版默认启用，
--copy-back后文件标签异常，MySQL 拒绝读取，报错像Permission denied on './mysql/user.MYD'，此时要restorecon -Rv /var/lib/mysql - 忘记清理旧
binlog：如果原库启用了log_bin，恢复后 MySQL 会尝试读取备份时记录的binlog文件（见xtrabackup_binlog_info），但该文件在新环境不存在，导致启动卡住；应删掉my.cnf中的log_bin行，或手动创建空 binlog 文件
my.cnf 的真实路径、datadir 权限模型、以及目标机的磁盘和内核限制。这些细节不会出现在日志里，但会在关键时刻决定你是花 12 分钟还是 120 分钟把库拉起来。
