必须用xtrabackup8.0且严格链式增量：第一次增量基于全量目录（--incremental-basedir=/backup/full），第二次必须基于第一次增量目录（--incremental-basedir=/backup/inc1），跳过中间层或版本不匹配将导致LSN校验失败、恢复失败。
xtrabackup 对 MySQL 8.0 做增量备份，必须用 xtrabackup8.0（不是 2.4 或 8.4+），且增量只能链式追加，不能跳过中间层。用错版本或断链，恢复时直接报 LSN mismatch，备份等于白做。
增量备份命令怎么写（MySQL 8.0）
增量不是“独立备份”，而是基于上一次成功备份的 LSN 差值计算出来的物理页拷贝。所以--incremental-basedir 必须指向一个**完整、未被篡改的前序备份目录**，且该目录下必须有有效的 xtrabackup_checkpoints 文件。
- 全量备份后，先确认
/backup/full/xtrabackup_checkpoints存在，并记录其中的to_lsn值 - 第一次增量：用全量目录作 base
xtrabackup --backup --target-dir=/backup/inc1 --incremental-basedir=/backup/full --user=backup_user --password=xxx - 第二次增量：必须用
/backup/inc1，不能回到/backup/fullxtrabackup --backup --target-dir=/backup/inc2 --incremental-basedir=/backup/inc1 --user=backup_user --password=xxx - 所有备份建议通过
/etc/my.cnf或/root/.my.cnf的[client]段提供认证，避免命令行明文密码
为什么合并增量时要加 --apply-log-only
这个参数控制事务日志是否“回滚未提交事务”——它决定了备份集能否继续接受下一次增量。- 全量准备：
xtrabackup --prepare --target-dir=/backup/full
默认会回滚 + 前滚，得到可直接启动的状态（但不能再合并增量） - 合并第一次增量：
xtrabackup --prepare --apply-log-only --target-dir=/backup/full --incremental-dir=/backup/inc1
只重放日志、不回滚，保留“可继续合并”的一致性窗口 - 合并最后一次增量：
xtrabackup --prepare --target-dir=/backup/full --incremental-dir=/backup/inc2
不加--apply-log-only，完成最终回滚与前滚，生成完整一致状态
漏掉、多加、或加错位置（比如加在最后一次合并上），都会导致 from_lsn 和 to_lsn 对不上，xtrabackup_checkpoints 校验失败。
常见失败现象和快速定位方法
实际卡在--prepare 阶段，90% 是 LSN 断链，不是磁盘满或权限问题：
-
innodb: Error: log file ./ib_logfile0 is of different size
说明/backup/full被手动清空、覆盖，或不是原始全量备份起点 -
Failed to find valid checkpoint in incremental backup
检查/backup/inc1/xtrabackup_checkpoints的from_lsn是否等于/backup/full/xtrabackup_checkpoints的to_lsn -
Invalid argument: --incremental-basedir does not exist
路径拼写错误，或目标目录是空文件夹（不是备份目录）
每次执行前，用 ls -l /backup/*/xtrabackup_checkpoints 快速扫一眼各层 LSN 是否连续，比等报错再排查快得多。
链式依赖这件事，没法取巧。哪怕只缺一次增量，整个链条就断了——备份目录看着都在，恢复时却永远卡在 LSN 校验。
