mysql 5.7 必须使用 percona xtrabackup 2.4.x，全量备份是增量前提且必须成功生成 xtrabackup_checkpoints 文件；增量备份严格依赖该文件中的 to_lsn 值，--incremental-basedir 必须精确指向含有效 checkpoints 的最内层时间戳子目录，否则静默损坏不可逆。
MySQL 5.7 必须用 Percona XtraBackup 2.4.x，且增量备份不能跳过全量、不能指错 --incremental-basedir 路径，否则备份文件在恢复时直接失效——不是报错失败，而是静默“可用但实际损坏”。
全量备份是硬前提，且必须成功生成 xtrabackup_checkpoints
增量备份不认时间、不认目录名，只读取上一次备份目录里 xtrabackup_checkpoints 文件中的 to_lsn 值。没有这个文件，--incremental-basedir 就失去意义。
- 全量命令必须带
--backup和--target-dir，例如：xtrabackup --backup --target-dir=/data/backup/full_20260812 --user=backup_user --password=xxx - 默认会生成带时间戳的子目录（如
full_20260812/2026-08-12_22-15-33），xtrabackup_checkpoints就在该子目录下 - 执行完立刻检查：
ls -l /data/backup/full_20260812/*/xtrabackup_checkpoints—— 若不存在，说明备份没写入成功，别往下走 - 别用
innobackupex：它是封装脚本，MySQL 5.7 下参数映射容易出错；直接调xtrabackup二进制更可控
--incremental-basedir 必须精确指向含有效 xtrabackup_checkpoints 的目录
XtraBackup 不校验路径是否存在，只打开 $basedir/xtrabackup_checkpoints 读 LSN。指错路径不会报错，但会导致后续所有增量都基于错误 LSN，恢复时数据缺失不可逆。
- 第一次增量：指向全量备份的**最内层时间戳子目录**，不是全量顶层目录。例如：
--incremental-basedir=/data/backup/full_20260812/2026-08-12_22-15-33 - 第二次增量：指向**第一次增量的最内层子目录**，不是全量目录，也不是第一次增量的顶层目录
- 脚本中必须先
test -f $basedir/xtrabackup_checkpoints，再执行增量命令；否则 LSN mismatch 错误可能被忽略 - 不要依赖
--no-timestamp：它让路径管理变脆弱；默认带时间戳虽多一层路径，但避免命名冲突和覆盖风险
每次增量后必须立刻 --prepare --apply-log-only
增量备份目录本身不能直接恢复，也不能单独 --prepare。它必须和全量一起按顺序合并。如果只推送备份、不做准备，半年后恢复时才发现“日志没应用”，就只能重来。
- 全量备份准备时加
--apply-log-only：xtrabackup --prepare --apply-log-only --target-dir=/data/backup/full_20260812/2026-08-12_22-15-33 - 每次增量备份完成后，立刻对它做
--prepare --apply-log-only：xtrabackup --prepare --apply-log-only --target-dir=/data/backup/inc_20260813/2026-08-13_03-10-22 - 注意：
--apply-log-only是关键，漏掉会导致全量数据被“提交”，无法再叠加增量 - 恢复前的最终
--prepare（不加--apply-log-only）只对全量目录执行一次，用于收尾
最容易被忽略的是：LSN 不是时间戳，也不是文件修改时间，它来自 InnoDB 页面内部；xtrabackup_checkpoints 文件一旦丢失或被手动修改，整个增量链就断了——而 XtraBackup 不会主动校验它的逻辑有效性，只当它是“权威输入”。
