全量备份是拍当前数据库完整快照，不依赖历史状态；增量备份只捕获自上次任意备份以来LSN或binlog新增变更，必须依赖前序备份链。
全量备份和增量备份的底层差异在哪
区别不在“要不要备份”，而在“以谁为基准、备份什么”。全量备份是拍一张当前数据库的完整快照，不管数据有没有变过；增量备份只抓自上次任意备份（全量或增量）以来 LSN 或 binlog 里新增的变更记录。
这导致两个根本性不同：
- 全量备份文件独立存在，恢复时只需它自己；
- 增量备份文件永远依赖前序备份，缺一份就断链。
mysqldump + binlog 增量方案的实际限制
很多人以为 mysqldump 配合 mysqlbinlog 就是标准增量方案，但其实它只是「逻辑增量」，不是真正意义上的增量备份。
关键问题在于：
-
mysqldump --single-transaction生成的是 SQL 文件，本身不带 LSN，无法做物理页级增量； -
mysqlbinlog导出的是语句/事件流，必须按顺序重放，且不能跳过中间某段 —— 如果mysql-bin.000003损坏，000004就无法安全应用； - 没有自动校验机制，
mysqlbinlog --start-position写错一个数字，可能跳过关键事务或重复执行。
增量备份恢复失败最常见的三个原因
生产环境里，90% 的增量恢复失败不是因为命令写错，而是因为链路完整性被破坏：
- 全量备份后没执行
FLUSH LOGS，导致后续binlog文件名重叠或位点不可追溯； - 误删了中间某份
mysql-bin.0000xx文件，而没意识到它在恢复链中不可跳过； - 用
--stop-datetime恢复时，时间精度只到秒，但同一秒内可能有多个事务，容易切在事务中间导致数据不一致。
XtraBackup 的增量备份为什么更可靠
Percona XtraBackup 是少数真正支持物理级增量备份的工具，它直接基于 InnoDB 的 LSN 值做页级筛选：
- 每次增量备份都记录起始
LSN和结束LSN，可精确对齐； - 支持增量备份之间的嵌套（比如全量 → 增量1 → 增量2），且每个增量包自带校验信息；
- 恢复时不需要重放 SQL，而是直接合并数据页，速度更快、一致性更强。
但代价是：必须停库或锁表才能保证一致性（除非用 --parallel + --safe-slave-backup 等组合），而且不能跨 MySQL 大版本恢复。
