xtrabackup增量备份必须基于全量备份，依赖xtrabackup_checkpoints中的to_lsn值，--incremental-basedir须精确指向前一次备份目录，且每次增量后需立即执行--prepare --apply-log-only，否则备份不可用。
必须用 xtrabackup --backup 配合 --incremental-basedir，不能跳过全量备份直接做增量，也不能混淆 --prepare 和 --backup 阶段。
全量备份是增量的前提，且必须成功生成 xtrabackup_checkpoints
增量备份不是按时间算的，它依赖上一次备份目录里的 xtrabackup_checkpoints 文件中记录的 to_lsn 值。没有这个文件，增量命令会报错或静默失败。
- 全量命令必须带
--backup和--target-dir，例如：xtrabackup --backup --target-dir=/data/backup/mysql/full_20260701 --user=backup_user --password=xxx - 不要用
--no-timestamp除非你脚本里能严格管理路径；默认生成带时间戳的子目录（如full_20260701/2026-07-01_14-22-33），xtrabackup_checkpoints就在该子目录下 - 执行完后立刻检查：
ls -l /data/backup/mysql/full_20260701/*/xtrabackup_checkpoints—— 如果不存在，说明备份没写入成功，别往下走 - MySQL 5.7 必须配 Percona XtraBackup 2.4.x，
xtrabackup --version输出应含2.4.，不是 8.0 或 2.3
--incremental-basedir 指向必须精确，不能靠“最近目录”模糊匹配
第二次增量不是指向全量目录，而是指向第一次增量目录；XtraBackup 不校验路径是否存在，只读取 xtrabackup_checkpoints 里的 LSN。指错就导致备份无效，恢复时才发现。
- 第一次增量：
xtrabackup --backup --target-dir=/data/backup/mysql/inc_20260702_01 --incremental-basedir=/data/backup/mysql/full_20260701/2026-07-01_14-22-33 - 第二次增量：
xtrabackup --backup --target-dir=/data/backup/mysql/inc_20260702_02 --incremental-basedir=/data/backup/mysql/inc_20260702_01（注意：是上一个增量目录，不是全量） - 脚本里必须先
test -f $basedir/xtrabackup_checkpoints，再执行增量，否则LSN mismatch错误不会中断流程，但备份不可用 - 别用
innobackupex—— MySQL 5.7 虽仍支持，但它只是xtrabackup的封装，参数映射易出错；直接用xtrabackup二进制更可控
备份后不 --prepare 就推送，等于存了一堆废文件
增量备份目录本身不能直接恢复，必须和全量一起按顺序 --prepare。如果只推送到远程却没做准备，半年后要恢复时才发现所有增量都“没应用日志”，就只能重来。
- 每次增量完成后，立刻对它做
--prepare --apply-log-only（注意加--apply-log-only）：xtrabackup --prepare --apply-log-only --target-dir=/data/backup/mysql/full_20260701/2026-07-01_14-22-33，再对第一个增量做同样操作，最后对最后一个增量去掉--apply-log-only - 远程存储前，确保本地已跑完
--prepare；否则 rsync 推送的是原始增量包，恢复链断裂 -
--apply-log-only的作用是把增量“合并进”上一级，但不回滚未提交事务——这是为了给下一次增量留出可叠加的基础 - 别省略
--datadir参数（尤其当 MySQL 数据目录不在默认位置时），否则--prepare可能因找不到 ibdata1 而失败
最容易被忽略的是：增量备份过程不校验上一级 xtrabackup_checkpoints 是否有效，也不校验 LSN 连续性。脚本里必须手动验证，而不是相信 “命令返回 OK” 就万事大吉。
