根本原因是LSN链断裂，即增量备份起点LSN与全量或前次增量终点LSN不匹配；xtrabackup通过xtrabackup_checkpoints中to_lsn校验连续性，不连续则报错退出。
根本原因不是备份命令写错了，而是LSN链断了——增量备份的起点LSN和全量（或前一次增量）的终点LSN对不上。
为什么xtrabackup报“LSN不连续”
LSN是InnoDB内部的字节级日志序列号，xtrabackup靠它精确识别哪些数据页被修改过。每次备份完成后，xtrabackup_checkpoints文件里会记录to_lsn，这就是该备份的“终点”。下一次增量必须以这个to_lsn为起点，否则就叫“不连续”。
- 全量备份目录里的
xtrabackup_checkpoints含to_lsn = 123456789 - 你却用
--incremental-basedir=/backup/inc1/去指向上一次失败的增量目录，而它的xtrabackup_checkpoints里to_lsn是123450000（中间缺了一段） - xtrabackup发现
123450000 ≠ 123456789，直接报错退出
怎么验证LSN是否真的连续
别猜，直接查文件：
cat /backup/full/xtrabackup_checkpoints | grep to_lsn cat /backup/inc1/xtrabackup_checkpoints | grep to_lsn cat /backup/inc2/xtrabackup_checkpoints | grep to_lsn
输出应该严格递增，比如：
-
to_lsn = 100000000（全量） -
to_lsn = 100050234（inc1） -
to_lsn = 100088765（inc2）
如果出现100000000 → 100088765 → 100090000，说明inc1缺失或损坏，inc2不能直接连到全量上。
修复LSN链的实操步骤
必须从最后一个完好的备份点重建链条，跳过损坏环节：
- 确认
/backup/full/和/backup/inc1/都完整（校验backup_variables.txt和xtrabackup_checkpoints存在且可读） - 如果
inc1损坏，就放弃它，用inc2直接基于全量重做：xtrabackup --backup --incremental --incremental-basedir=/backup/full/ --target-dir=/backup/inc2_new/ - 千万别手动改
xtrabackup_checkpoints里的to_lsn——这会导致数据页不一致，恢复后可能崩溃 - 若必须跨主机迁移备份集，不能依赖
--incremental-base=history:last_backup，得用--incremental-base=dir:/path/to/prev_inc并确保路径下有完整的backup_variables.txt
prepare时最容易踩的坑
LSN连续只是前提，prepare顺序和参数错一个，照样白忙活：
- 全量prepare必须加
--apply-log-only：xtrabackup --prepare --apply-log-only --target-dir=/backup/full/ - 每个增量prepare也必须加
--apply-log-only，包括最后一个：xtrabackup --prepare --apply-log-only --target-dir=/backup/full/ --incremental-dir=/backup/inc1/ - 只有在所有增量都apply完后，最后一次prepare才去掉
--apply-log-only：xtrabackup --prepare --target-dir=/backup/full/ - 漏掉任何一次
--apply-log-only，或者顺序颠倒（比如先apply inc2再apply inc1），最终ibdata1和redo日志状态就会错乱
LSN链是物理备份的生命线，它不像binlog可以跳过某条记录——断了就是断了，没得商量。日常运维中，比写对命令更重要的是每轮备份后立刻校验xtrabackup_checkpoints，并在脚本里加入自动比对逻辑。
