物理备份恢复失败主因是MySQL与XtraBackup版本不匹配或重做日志不兼容：需确保主版本号完全一致，删除目标目录下ib_logfile*，核对innodb_log_file_size，并根据加密配置调整innodb_redo_log_encrypt。
物理备份恢复失败，八成卡在版本或日志不匹配上——不是文件损坏，而是 MySQL 拒绝启动。
检查 MySQL 与 XtraBackup 版本是否严格一致
XtraBackup 8.0 只能用于 MySQL 8.0 系列，混用会直接报错 InnoDB: Unsupported redo log format 或静默失败。MySQL 5.7 备份用 XtraBackup 8.0 恢复，哪怕看起来“成功”，后续启动时也可能在加载表空间阶段崩溃。
- 执行
mysql --version和xtrabackup --version，确认主版本号（第一个数字）完全相同，例如都是8.0.33 - 若使用 Percona Server，请确保 XtraBackup 版本后缀也匹配（如
percona-xtrabackup-80-8.0.33-25.1.el8） - 不要依赖“大版本差不多就行”的经验——
8.0.33和8.0.34之间可能有 redo log 格式微调，跨小版本恢复需查官方 release note
验证 ib_logfile* 是否与目标实例兼容
MySQL 启动时会校验 ib_logfile0 和 ib_logfile1 的格式、大小、checksum。旧版备份带的重做日志文件，新版本 MySQL（尤其是启用了 innodb_redo_log_capacity 或 innodb_redo_log_encrypt 的 8.0.30+）可能直接拒绝加载。
- 恢复前务必删除目标数据目录下的
ib_logfile*文件（不是备份里的，是目标空目录里预生成的或残留的） - 确保备份中不含
ib_logfile*—— XtraBackup 全量备份默认不打包它们；若手动拷贝了，请立刻移除 - 启动 mysqld 前，确认
innodb_log_file_size与源库一致：查源库SELECT @@innodb_log_file_size;，并在目标my.cnf中显式设置
跳过重做日志应用但保留数据一致性
有时你只想快速拉起服务验证数据，不追求事务精确回放。可用 --apply-log-only 配合 --use-memory 加速 prepare，但注意这会跳过未提交事务的回滚和已提交事务的重做日志重放。
- 仅限测试环境或灾备演练：运行
xtrabackup --prepare --apply-log-only --target-dir=/path/to/backup - 后续必须再执行一次不带
--apply-log-only的--prepare才能真正启用该备份（否则启动报Tablespace is not found） - 若备份含增量，所有增量必须按顺序
--apply-log-only，仅最后一次全量 prepare 不加该参数
最常被忽略的是：你以为删掉了 ib_logfile* 就万事大吉，其实 innodb_redo_log_encrypt=ON 这种 8.0.30+ 新增配置，会让旧备份的 redo 日志无法解密——此时必须在目标 my.cnf 中显式设为 OFF，哪怕源库没开加密。
