必须执行--prepare，因为备份是“一致性快照+未刷盘日志”的混合状态，该步骤通过重放redo log使数据文件达到崩溃恢复后的干净状态，跳过则mysql启动时易因日志不完整而卡住或报页损坏错误。
xtrabackup 恢复不是“一键还原”，而是分阶段的物理文件重建过程。它不支持单库恢复，必须整实例还原，且恢复前必须完成 --prepare —— 否则直接 --copy-back 会启动失败或数据损坏。
为什么恢复前必须执行 --prepare
备份生成的是“一致性快照+未刷盘日志”的混合状态，--prepare 的作用是把 redo log 中的变更重放（apply）到数据文件中，使所有 .ibd 和 ibdata1 达到崩溃恢复后的干净状态。跳过这步，MySQL 启动时会尝试自己 recovery，但大概率因日志不完整而卡住或报错 innodb: Database page corruption on disk。
-
--apply-log-only仅用于全量备份和中间增量备份的 prepare 阶段，避免回滚未提交事务，为后续增量合并留出空间 - 最后一次 prepare（含最终全量或合并完所有增量后）不能加
--apply-log-only，否则 MySQL 启动时会拒绝加载 - 如果备份是压缩的（如
.qp），需先用xtrabackup --decompress解压，再--prepare
--copy-back 失败的常见原因
--copy-back 把准备好的备份文件复制到 MySQL datadir，但它不检查目标目录是否为空、权限是否正确、配置文件是否匹配——这些都得你手动确认。
- MySQL 必须已停止：
systemctl stop mysqld或kill -15 $(cat /var/run/mysqld/mysqld.pid) -
datadir必须为空：执行rm -rf /var/lib/mysql/*（注意路径！不同部署方式位置不同） - 必须指定
--defaults-file：否则xtrabackup无法读取datadir路径，报错Error: datadir must be specified - 恢复后需修复属主：
chown -R mysql:mysql /var/lib/mysql，否则启动时报Permission denied
MySQL 8.0 与 XtraBackup 版本不匹配的典型表现
MySQL 8.0 引入了新的数据字典格式和 redo log 结构，xtrabackup 2.4 完全不兼容，强行使用会报类似 Unsupported redo log format 或 Failed to read header from file ./ib_logfile0。
- MySQL 5.7 → 用
percona-xtrabackup-24（如 2.4.26） - MySQL 8.0 → 用
percona-xtrabackup-80（如 8.0.30-23） - MySQL 8.1+ → 必须用
percona-xtrabackup-81 - 验证方式：
xtrabackup --version输出应含 “based on MySQL 8.0” 字样
恢复后 MySQL 启动失败怎么办
最常被忽略的是 mysql 系统库权限表没生效，或 performance_schema 表结构损坏。不要急着重启，先看错误日志：
- 查日志：
tail -n 50 /var/log/mysqld.log，重点关注InnoDB initialization和Failed to open mysql.user类错误 - 若提示
Table 'mysql.user' doesn't exist：说明--copy-back没包含系统库，检查备份目录里是否有mysql/子目录，以及--prepare是否成功完成 - 若卡在
Starting crash recovery：大概率--prepare没做或中途中断，重新执行并加--verbose观察输出 - 启动后立即执行：
mysql -uroot -p -e "SELECT COUNT(*) FROM mysql.user;"，确认系统库可读
--prepare 是不可跳过的隐性关卡，--copy-back 是路径与权限的显性雷区，版本错配则是底层协议级的硬伤——三者任一出问题，恢复就停在半途。
