最稳妥的入门组合是mysqldump + crontab，适用于中小规模MySQL实例；需确保UTF-8编码防中文乱码，mysqldump路径无空格，启用log-bin后每日全备并FLUSH LOGS切日志，再用mysqlbinlog按时间范围提取增量。
mysqldump + crontab 是最稳妥的入门组合
对绝大多数中小规模 MySQL 实例（单库 mysqldump 配合 Linux 的 cron 是最可控、最易排查、兼容性最好的方案。它不依赖额外服务，也不需要修改 MySQL 配置，只要账号有 SELECT 和 LOCK TABLES 权限就能跑起来。
常见错误现象：备份脚本手动执行成功，但 cron 下失败 —— 多半是环境变量缺失（比如 PATH 不含 /usr/bin 或 /usr/local/mysql/bin），或密码含特殊字符未转义。
- 脚本开头显式声明 PATH：
PATH=/usr/local/bin:/usr/bin:/bin - 避免在命令行直接写
-p密码，改用配置文件（~/.my.cnf）并设权限chmod 600 ~/.my.cnf -
mysqldump加--single-transaction（InnoDB 必选），否则备份期间表锁可能导致业务阻塞 - 输出重定向必须用绝对路径，cron 默认工作目录是用户 home，相对路径极易出错
备份脚本里必须处理的三个硬性细节
一个能长期跑下去的备份脚本，光导出 SQL 不够。漏掉下面任意一点，几个月后可能发现磁盘写满、备份损坏却毫无察觉。
- 压缩：用
gzip而不是zip，前者更轻量、Linux 原生支持；命令写成mysqldump ... | gzip > /path/to/backup.sql.gz - 清理：用
find按修改时间删旧文件，别用ls | head -n这类不可靠方式；示例：find /backup -name "*.sql.gz" -mtime +7 -delete - 校验：备份后立即用
gunzip -t检查压缩包完整性，失败就发邮件或写日志；别等恢复时才发现文件损坏
Windows 上用任务计划程序容易踩的坑
Windows Server 环境下，mysqldump 路径、编码、权限三座大山挡在自动备份前面。任务计划程序默认以 SYSTEM 身份运行，但该身份通常没有 MySQL 登录权限。
- 务必在“安全选项”里勾选“不管用户是否登录都要运行”，并填入有 MySQL 访问权限的专用账号（如
mysqlbkp） -
.bat脚本第一行加chcp 65001 > nul切换 UTF-8 编码，否则中文库名/表名会乱码 -
mysqldump路径不能带空格（如"C:\Program Files\..."），要么改用短路径C:\Progra~1\...，要么把mysqldump.exe复制到无空格目录 - 测试阶段先手动双击运行 .bat，确认输出无报错再丢进任务计划
增量备份不是“高级功能”，而是空间和恢复时间的刚需
全量备份每天一次，数据量超过 10GB 后，网络传输、存储占用、恢复耗时都会陡增。这时必须引入基于二进制日志（binlog）的增量备份，但前提是 MySQL 已启用 log-bin。
关键动作只有两步：一是每天全备后执行 mysql -e "FLUSH LOGS" 切新 binlog；二是用 mysqlbinlog 提取指定时间范围的日志，例如：mysqlbinlog --start-datetime="2026-07-01 02:00:00" --stop-datetime="2026-07-02 02:00:00" /var/lib/mysql/mysql-bin.000001 > incr_20260701.sql。
注意：expire_logs_days 必须设为大于等于保留天数（如保留 7 天增量，则设为 8），否则 FLUSH LOGS 可能误删还在用的 binlog 文件。
