xtrabackup全量备份需指定--target-dir且目录须为空，增量备份依赖--incremental-basedir准确指向上次有效备份根目录，恢复时须按序--apply-log--redo-only合并再完结。
全量备份用 xtrabackup --backup，但必须加 --target-dir 且不能重复写入同一目录
全量备份不是“一键导出 SQL”，而是拷贝 InnoDB 数据文件+redo 日志的物理快照。直接运行 xtrabackup --backup 会失败，因为默认没指定目标路径。
-
--target-dir=/path/to/backup是必需参数，路径必须为空或不存在（xtrabackup 不会覆盖已有备份） - 备份前确保 MySQL 正在运行，且
xtrabackup进程有权限读取datadir和写入目标路径 - 若用非 root 用户执行，需提前配置
my.cnf中的[client]段落，提供user和password，否则报错Access denied for user ''@'localhost' - 备份过程不锁表，但会产生 I/O 压力；生产环境建议避开高峰，并用
--throttle限速（如--throttle=100表示每秒最多 100 个 IO 请求）
增量备份依赖 --incremental-basedir，必须指向上一次（全量或上一个增量）的 xtrabackup_checkpoints
增量不是“只备份新数据”，而是基于上一次备份的 LSN（日志序列号）做差异拷贝。关键在于 --incremental-basedir 必须准确指向含有效 xtrabackup_checkpoints 文件的目录——不是任意备份目录，而是上次成功完成的备份根目录。
- 第一次增量：基于全量备份目录，例如
--incremental-basedir=/backup/full_20240501 - 第二次增量：必须基于第一次增量目录，不是再次基于全量目录，否则恢复时会跳过中间变更
- 误用
--incremental-basedir指向错误路径，xtrabackup会报错Failed to read metadata from xtrabackup_checkpoints或静默生成无效备份 - 每次增量备份后，
xtrabackup_checkpoints中的to_lsn就是下一次增量的from_lsn，可手动检查验证
恢复时先 --apply-log --redo-only 全量，再逐个合并增量，最后才 --apply-log 完结
恢复不是“把备份文件 cp 回 datadir”那么简单。InnoDB 需要重放 redo 日志才能保证一致性，而增量备份的日志必须按顺序合并进全量，否则数据页会损坏。
- 全量备份目录先执行：
xtrabackup --apply-log --redo-only --target-dir=/backup/full_20240501 - 依次合并每个增量（顺序不能错！）：
xtrabackup --apply-log --redo-only --target-dir=/backup/full_20240501 --incremental-dir=/backup/inc_20240502 - 最后一个增量合并完，去掉
--redo-only再跑一次--apply-log，才算最终一致性状态 - 如果漏掉某次增量，或顺序颠倒，
--apply-log可能卡住、报错LSN is out of bounds，甚至生成不可启动的数据库
增量同步靠 --log-stream + xbstream 实时捕获日志，但仅适用于 MySQL 8.0+ 且需开启 binlog
真正意义上的“增量同步”不是定期打增量包，而是持续拉取 binlog 并应用到备库。xtrabackup 的 --log-stream 模式本质是把 redo 日志流式输出，配合 xbstream 压缩传输，适合长连接低延迟场景，但限制很多。
- MySQL 必须启用
binlog（log_bin=ON），且binlog_format=ROW；否则无法保证 DML 精确回放 -
--log-stream只支持 MySQL 8.0.26+，旧版本直接报错unknown option '--log-stream' - 命令示例：
xtrabackup --backup --log-stream | xbstream -c > backup.xbstream；接收端用xbstream -x 解包 - 该模式不包含 DDL 同步逻辑，建表、删索引等操作仍需额外处理（比如监听
mysql.general_log或解析 binlog）
xtrabackup_checkpoints 文件的完整性校验和备份目录的归属权限。哪怕只是 chown 错了用户，恢复时 mysqld 启动就会因无法读取 ibdata1 报错 InnoDB: Operating system error number 13。 
