CentOS 7.9 上的 MySQL 5.7 用 xtrabackup 2.4 做全备，恢复到新实例后起不来，error log 里是 The log sequence number 3215478921 in the system tablespace is higher than the log sequence number in the ib_logfile，按 ib_logfile 大小不一致重建了一遍再启动，报错一字不差。
真正麻烦的地方在于，几个原因的现象几乎一样。备份目录是 –stream=tar 解出来的，–prepare 这一步漏了或者中途被打断。还有一种是备份期间有 DDL，redo 里的事务没 apply 完就把数据目录拷去启动。
少数情况下是拷文件时漏了 xtrabackup_logfile 和 xtrabackup_checkpoints 两个文件。
动手时先看备份处于哪个阶段
cat /backup/full/xtrabackup_checkpoints接着执行 prepare 让 redo 落盘
xtrabackup --prepare --target-dir=/backup/full拷回数据目录并改属主
xtrabackup --move-back --target-dir=/backup/full等前面都确认过，再启动并盯 error log
systemctl start mysqld && tail -f /var/log/mysqld.log白天有业务在跑，能验证的部分都压到了晚上做。
当时还开着另一个排查窗口，两边日志对照着看才定位到。
恢复的判定其实很直接。xtrabackup_checkpoints 里 last_lsn 等于备份的 to_lsn，mysqld 启动后 error log 不再出现 LSN 报错，关键表 count 与备份前记录一致。
这里还有个坑。prepare 必须在目标机器上重跑一次，跨版本恢复尤其如此；move-back 会清空原数据目录，动手前把那台机的旧库先挪走。同一份配置在测试环境跑通，不代表线上没事，两边的默认值经常不一样。