什么是 xtrabackup 增量备份的起点
增量备份不是凭空开始的，必须基于一个有效的全量备份（
full backup）。xtrabackup 不会自动帮你找上一次备份位置或校验其一致性，
--incremental-basedir必须明确指向一个成功完成、且未被修改过的全备目录。如果该目录下
xtrabackup_checkpoints文件丢失或
to_lsn字段不完整，后续所有增量都会失败。 全备必须用
xtrabackup --backup --target-dir=/data/backup/full_20240501/执行，不能用
--prepare提前应用日志 每次增量前检查目标
basedir是否包含完整的
xtrabackup_checkpoints，且其中
backup_type = full-backuped或上一次增量的
incremental不要手动修改
xtrabackup_checkpoints，LSN 值错一位，恢复时就会卡在
Applying log
执行增量备份时的关键参数组合
增量命令本身简单，但参数稍有错位就生成无效备份。核心是区分「基于谁」和「存到哪」，且不能混淆
--incremental和
--incremental-basedir的语义。
--incremental是开关，值是目标路径（如
/data/backup/inc_20240502/），不是源路径
--incremental-basedir必须是上一次备份的绝对路径（全备或上一个增量），且该目录下要有
xtrabackup_checkpoints第二次及以后的增量，
--incremental-basedir应该指向上一次增量目录，不是原始全备目录（除非你刻意做“累积增量”） 建议加
--no-timestamp避免自动生成子目录，让路径更可控
xtrabackup --backup \ --incremental /data/backup/inc_20240502/ \ --incremental-basedir=/data/backup/full_20240501/ \ --no-timestamp \ --user=backup_user \ --password=xxx
准备（prepare）增量备份链的顺序和陷阱
恢复前必须把全备和所有增量按顺序合并，这个过程叫
prepare。顺序错误、跳过某次增量、或对全备用了
--apply-log-only不当，都会导致最终数据不一致。 先 prepare 全备：用
xtrabackup --prepare --apply-log-only --target-dir=/data/backup/full_20240501/再按时间顺序逐个 apply 增量：每次都要加
--apply-log-only，包括最后一个增量（除非你确定不再追加） 最后一个增量 prepare 完后，去掉
--apply-log-only运行一次，才算真正可恢复状态 注意：prepare 过程会修改原备份目录内容，不要在生产环境直接操作未备份的备份集
# 全备准备（只 apply 日志，不回滚未提交事务） xtrabackup --prepare --apply-log-only --target-dir=/data/backup/full_20240501/ <h1>第一次增量合并进去</h1><p>xtrabackup --prepare --apply-log-only \ --target-dir=/data/backup/full_20240501/ \ --incremental-dir=/data/backup/inc_20240502/</p><h1>最后一次增量（假设是 inc_20240503），这次不加 --apply-log-only</h1><p>xtrabackup --prepare \ --target-dir=/data/backup/full_20240501/ \ --incremental-dir=/data/backup/inc_20240503/
验证增量备份是否真的有效
很多团队做完备份就认为万事大吉，直到恢复时才发现某次增量的 LSN 断层或磁盘写入不完整。最轻量的验证方式是检查每个备份目录下的
xtrabackup_checkpoints是否连贯。 全备的
to_lsn应等于第一个增量的
from_lsn每个增量的
to_lsn应等于下一个增量的
from_lsn用
grep -E "(from_lsn|to_lsn)" /path/to/backup/xtrabackup_checkpoints快速比对 真正可靠的验证是定期用
--copy-back恢复到隔离环境，并连接 MySQL 执行
SELECT COUNT(*) FROM mysql.innodb_table_stats;类似轻量查询
LSN 链断裂、
backup_type = invalid、或
xtrabackup_binlog_info缺失，都是备份流程中某个环节静默失败的信号——别只看命令返回 0。
