MySQL无原生增量备份命令，需靠开启binlog实现；必须配置log-bin、server-id和ROW格式；真实策略为“全量备份+持续binlog归档”；恢复需精准定位position或时间点。
MySQL 本身不提供“增量备份”命令，靠 binlog 实现
MySQL 没有 mysqldump --incremental 这种原生命令。所谓“增量备份”，本质是开启并管理二进制日志（binlog），把所有 DML/DDL 操作（除 SELECT）按时间顺序记下来。恢复时用 mysqlbinlog 解析 + mysql 回放，就能还原某段时间的数据变化。
常见错误现象：SHOW MASTER STATUS 返回空、log_bin 变量为 OFF、mysqlbinlog 报错 “File not found”——基本都是没开 binlog 或路径配置错误。
- 必须在
[mysqld]段落中添加log-bin=/var/lib/mysql/mysql-bin（建议用绝对路径） - 必须设置
server-id=1（主从或备份场景下不可为 0） -
binlog_format推荐用ROW：避免函数、触发器、非确定性语句导致主从/恢复不一致 - 重启 MySQL 后执行
SHOW VARIABLES LIKE 'log_bin';确认返回ON
全量 + binlog 是生产级增量备份的最小可行组合
只靠 binlog 无法从零恢复——它不包含初始结构和数据。所以真实备份策略永远是：一次全量 + 持续归档 binlog。
全量备份推荐用 mysqldump（逻辑）或 percona-xtrabackup（物理），取决于你的引擎和停机容忍度：
-
mysqldump -u backup -p --single-transaction --routines --triggers --databases db1 > full_$(date +%F).sql——适合中小库，需确保事务一致性 -
innobackupex --user=backup --password=xxx /backup/full/——适合大库、InnoDB 表多、不能锁表的场景 - 每次全备后立即执行
FLUSH LOGS，生成新 binlog 文件，方便后续按文件粒度归档 - binlog 归档不能只靠保留文件：要用定时任务把
mysql-bin.0000xx复制到异地存储，并清空已归档的老日志（配合PURGE BINARY LOGS）
恢复时最容易漏掉的关键点：position 和时间窗口
恢复不是简单回放所有 binlog。你得精准定位“从哪开始、到哪结束”。比如误删表后想恢复到删除前一秒，就必须知道两个坐标：
- 全备对应的
binlog起始位置（来自全备时的SHOW MASTER STATUS输出，或xtrabackup_binlog_info文件） - 误操作发生前的
binlog结束位置（用mysqlbinlog --base64-output=decode-rows -v mysql-bin.000002 | grep -A5 -B5 "DROP TABLE"定位） - 若用时间恢复，务必确认服务器时区与 binlog 时间戳一致（
mysqlbinlog --start-datetime="2026-02-04 09:30:00"） - 跳过某条语句？用
--stop-position或--exclude-gtids（GTID 模式下更安全）
别把“差异备份”当“增量备份”用
有人用 mysqldump --where="updated_at > '2026-02-03'" 生成“增量 SQL”，这其实只是条件导出，不是真正意义的增量备份：
- 它依赖业务字段（如
updated_at），一旦字段为空、被绕过或时钟不准，就漏数据 - 不记录 DDL（建表、改列）、用户权限变更、存储过程等元数据
- 无法做精确时间点恢复（PITR），也不能应对误执行
DROP DATABASE这类灾难 - Percona XtraBackup 的
--incremental才是物理层增量：基于 InnoDB 数据页 LSN 差异，但必须接在全备之后，且只对 InnoDB 表有效
真正可靠的增量能力，始终建立在 binlog 开启、归档可靠、全量基线清晰这三根柱子上。少一根，恢复就可能卡在半路。
