增量备份必须依赖binlog，需先确认log_bin开启并配置正确；真增量只能用mysqlbinlog解析binlog，按position或时间截取；每次备份后须更新pos文件、执行flush-logs滚动日志，并安全清理旧日志。
增量备份必须依赖 binlog，先确认它开了没
没开 log_bin，脚本写得再好也白搭。执行 mysql -u root -p -e "SHOW VARIABLES LIKE 'log_bin';"，返回 ON 才行。如果关着，得改 /etc/my.cnf，加两行：
[mysqld] log-bin = /var/lib/mysql/mysql-bin server-id = 1
注意路径权限：确保 /var/lib/mysql/ 目录属主是 mysql:mysql，否则 MySQL 启动失败。改完必须重启服务：systemctl restart mysqld，再验证一次。
用 mysqlbinlog 抓增量，别用 mysqldump 做“假增量”
mysqldump 本身不支持真正意义上的增量——它只能全库或单库导出，所谓“增量备份脚本”里用它，本质是每天全量备份，靠删旧文件省空间，不是 binlog 级增量。真增量只有一种主流方式：用 mysqlbinlog 解析 binlog 文件，按时间或 position 截取变更。
- 先查当前日志位置：
mysql -u root -p -e "SHOW MASTER STATUS;" | awk 'NR==2 {print $1,$2}' - 上次备份的 position 记在哪？必须存文件（比如
/backup/binlog.pos），不能硬编码或靠脚本猜 - 生成增量 SQL：
mysqlbinlog --start-position=123456 --stop-datetime="2026-08-12 03:00:00" /var/lib/mysql/mysql-bin.000007 > /backup/inc_20260812.sql - 记得每次备份完更新
binlog.pos，否则下次就漏数据
脚本里 flush-logs 是关键动作，但别乱用 --delete-master-logs
每天备份前执行 mysqladmin -u root -p flush-logs，会滚动出新 binlog（如从 mysql-bin.000007 切到 mysql-bin.000008），这样当天的增量就限定在刚生成的那个文件里，逻辑清晰、不易错位。
但 --delete-master-logs 参数危险——它会直接删掉所有已备份的 binlog。如果数据库是主从架构，从库还没读完这些日志，删了就断复制。更安全的做法是：PURGE BINARY LOGS BEFORE '2026-08-05 00:00:00';，按时间删，留足缓冲。
crontab 定时要避开业务高峰，且必须重定向 stderr
别写成 0 3 * * * /backup/inc_bak.sh 就完事。真实环境必须：
- 指定 SHELL 和 PATH：
PATH=/usr/local/bin:/bin:/usr/bin - 捕获错误：
0 3 * * * /backup/inc_bak.sh >> /backup/inc_bak.log 2>&1 - 避免凌晨 3 点撞上慢查询或大事务，可随机延时：
sleep $((RANDOM \% 300))（最多延 5 分钟） - 检查上一次备份是否卡住：
pgrep -f "mysqlbinlog" || /backup/inc_bak.sh，防止堆积
binlog 文件名会变、position 会跳、服务器时间可能不准——这些细节不处理，脚本跑半年后某天突然恢复不了，你才知道什么叫“备份了等于没备”。
