1、现象
使用8.0.30的备份集进行恢复，执行prepare命令报错如下
网络上有人遇到相同的问题，说回退了旧的版本之后就没有出现，实验回退到使用8.0.30的版本进行prepare操作，的确成功了
2、原因分析
查看断言位置的代码，可以发现历史记录里，有一个提交重新计算了开始扫描的lsn位置
该提交主要是为了解决之前拷贝lsn不准的情况（8.0.30的xb）
解决的场景提交中也说的比较明白，即假如拷贝之前，server端又发生了一次checkpoint，在prepare阶段，扫描开始的位点，就可能搞错，导致认为异常
During backup phase, PXB first reads the checkpoint LSN(say LSN A) from redo
files and then copies the checkpoint header having checkpoint LSN (LSN B)
from redo file.
If server does a checkpoint after PXB read the checkpoint LSN and before
PXB copies the checkpoint header, then LSN A would be differnt from LSN B
During backup phase, PXB copies redo logs starting from LSN A.
But during prepare phase, PXB was setting redo file start LSN using checkpoint
header (LSN B).经测试验证，高版本代码注释掉set_lsn也可以正常进行prepare操作，即set_lsn这里出现了错误，进一步调试发现，为计算结果溢出，这也就是为啥有的环境必现，有的环境一直复现不出来。
如下图，此处的header_num、OS_FILE_LOG_BLOCK_SIZE、round_off均为uint32类型，程序计算结果的时候，直接就把结果以uint32输出，当lsn比较大时，就会出现溢出的情况，导致set_lsn异常
3、解决方案
如果修改xtrabackup代码，可以考虑将某个变量强制转换为lsn_t（即uint_64），如图
当前解决方案，backuprecovery使用恢复的包里添加8030的二进制，形如xtrabackup8030，恢复的时候解析xtrabackup_info文件，如果是8.0.30的备份工具备份的，使用xtrabackup8030进行prepare
