Windows MySQL自动备份bat脚本：定时备份与30天清理实践

Windows服务器上跑MySQL，最让我头疼的从来不是SQL写不好，而是备份这件事。装个图形工具固然省心，可一旦机器没装桌面环境、或者半夜两点数据库被搞挂了，能救命的往往还是那条不声不响的bat批处理脚本。这篇我把自己一直在用的自动备份脚本完整放出来，核心就两件事：每天定时把指定库通过mysqldump导成SQL文件，再顺手清理掉30天前的旧备份，全部由Windows任务计划程序调度，不依赖任何第三方工具。如果你是运维、兼职管服务器的开发，或者自己买了Windows云主机跑了MySQL，这份脚本直接改几行配置就能上岗。

1. 为什么Windows上的MySQL备份，绕不开bat批处理脚本

1.1 这个脚本解决的是哪类麻烦

先说清楚适用场景。中小公司的Windows Server上跑着MySQL，多半是内部OA、ERP、测试环境、个人网站后端这类负载不算高的库。这类环境往往没有预算上专业的备份软件，DBA岗位也不存在，备份这件事要么靠人肉每周导一次，要么干脆没人管。还有一个典型场景：开发机或测试服务器上的MySQL，数据丢了虽然不致命，但重建库表、补录测试数据非常浪费时间。

这个bat脚本就是用来填这个坑的。它做的是逻辑备份，用MySQL自带的mysqldump把指定数据库导出成一个完整的SQL文本文件。这个文件拿到任何一台装了MySQL的机器上都能恢复，跨平台、跨版本都很方便。它不解决增量备份、不解决实时灾备，但能保证"最坏情况下，我能找回30天内任意一天的完整数据"，这对绝大多数中小业务来说已经够了。

如果MySQL不在本机、在另一台Linux服务器上，这个脚本同样能用。只要本机能连通目标MySQL的3306端口、本机装了mysqldump.exe，远程库也能按时备份到Windows磁盘上。我实际就是这么干的——Linux上的业务库，Windows机器定时拉备份，统一收拢到一个目录，管理起来很省事。

1.2 为什么不是GUI工具，也不是PowerShell

可能有人问：用Navicat或者MySQL Workbench点几下不是更简单？确实简单，但没法自动化。你半夜两点不会爬起来点"导出"，服务器也不会因为今天是周五就自动备份。所有GUI工具都解决不了"无人值守定时执行"这个核心诉求，要么依赖任务计划程序去调用它的命令行接口，兜兜转转又回到脚本。

PowerShell相比bat，语法更现代、逻辑更强，但对国内大多数半路出家的运维来说，维护成本偏高。老旧的Windows Server 2008 R2、Win7上PowerShell版本参差不齐，还有一部分机器的执行策略默认禁用脚本。bat的好处是从Windows 95到Windows 11通吃，任务计划程序直接指向它就能跑，出了问题打开看一眼就能排查，对"能用就行"的场景来说，没有比它更合适的了。

1.3 整体设计：备份、校验、清理三步走

这个脚本的核心逻辑可以拆成三个动作：

• 备份：mysqldump导出指定库到备份目录，文件名带精确到秒的时间戳。
• 校验：通过mysqldump的退出码判断备份是否成功，成功才把文件大小写进日志，用于人工确认。
• 清理：用forfiles删除30天前的旧SQL文件，只保留最近30天的备份。

这里有一个很容易被忽略的设计原则：备份失败时必须跳过清理步骤。如果某天mysqldump因为密码过期、磁盘满等原因失败了，而清理逻辑还正常跑，就会把之前的好备份一并删掉，那就真的什么都没了。脚本里我让备份失败时直接exit /b 1，不让它继续往下走，这是底线。

2. 备份脚本完整拆解：从时间戳到forfiles清理

2.1 完整脚本，可直接复制保存

下面是完整的脚本，保存为mysql_backup.bat就能用。注意保存编码选ANSI，否则中文注释在cmd里会显示成乱码，虽然不影响逻辑，但排查问题的时候很痛苦。

@echo off setlocal enabledelayedexpansion title MySQL Auto Backup :: ========================================================== :: MySQL 自动备份 + 30天清理脚本 :: 基于 mysqldump + forfiles，不依赖第三方工具 :: 保存此文件为 ANSI 编码，避免中文注释乱码 :: ========================================================== :: ---------- 配置区：按实际情况修改 ---------- set "DB_HOST=127.0.0.1" set "DB_PORT=3306" set "DB_USER=root" set "DB_PASS=你的数据库密码" set "DB_NAME=你的库名" set "MYSQL_DUMP=C:\Program Files\MySQL\MySQL Server 8.0\bin\mysqldump.exe" set "BACKUP_DIR=D:\MySQLBackup" set "KEEP_DAYS=30" set "LOG_FILE=%BACKUP_DIR%\backup.log" :: ---------- 自动创建备份目录 ---------- if not exist "%BACKUP_DIR%" mkdir "%BACKUP_DIR%" :: ---------- 生成固定格式时间戳 ---------- for /f "tokens=2 delims==" %%i in ('wmic OS Get LocalDateTime /value ^| find "="') do set "DT=%%i" if not defined DT ( for /f "usebackq delims=" %%j in (`powershell -NoProfile -Command "Get-Date -Format 'yyyyMMdd_HHmmss'"`) do set "TS=%%j" ) else ( set "TS=!DT:~0,8!_!DT:~8,6!" ) echo ==================== >> "%LOG_FILE%" echo [%date% %time%] Backup start: %DB_NAME% >> "%LOG_FILE%" set "BACKUP_FILE=%BACKUP_DIR%\%DB_NAME%_%TS%.sql" :: ---------- 执行 mysqldump 备份 ---------- "%MYSQL_DUMP%" -h"%DB_HOST%" -P"%DB_PORT%" -u"%DB_USER%" -p"%DB_PASS%" --single-transaction --routines --triggers --events --default-character-set=utf8mb4 "%DB_NAME%" > "%BACKUP_FILE%" 2>> "%LOG_FILE%" if errorlevel 1 ( echo [%date% %time%] ERROR: mysqldump exit code = !errorlevel! >> "%LOG_FILE%" echo [%date% %time%] ERROR: Backup FAILED, cleanup skipped. >> "%LOG_FILE%" exit /b 1 ) for %%A in ("%BACKUP_FILE%") do set "FILE_SIZE=%%~zA" echo [%date% %time%] SUCCESS: %BACKUP_FILE% size=%FILE_SIZE% bytes >> "%LOG_FILE%" :: ---------- 清理超过 KEEP_DAYS 天的旧备份 ---------- echo [%date% %time%] Cleanup start: older than %KEEP_DAYS% days >> "%LOG_FILE%" forfiles /p "%BACKUP_DIR%" /m *.sql /d -%KEEP_DAYS% /c "cmd /c del /q @path" >> "%LOG_FILE%" 2>&1 echo [%date% %time%] Cleanup finished >> "%LOG_FILE%" echo [%date% %time%] All done >> "%LOG_FILE%" exit /b 0

2.2 配置区：改这六处就能跑

脚本开头就是配置区，我用分隔线标出来了。最需要留意的是MYSQL_DUMP这个路径。MySQL 8.0 默认装在C:\Program Files\MySQL\MySQL Server 8.0\bin，5.7则是MySQL Server 5.7。如果你安装时改了目录，或者机器上只装了MySQL客户端组件，路径要跟着改。如果系统提示找不到mysqldump，先用资源管理器去确认一下bin目录里到底有没有这个exe。

DB_HOST默认是127.0.0.1。备本机库就保持这个值，备远程库改成目标服务器IP。这里有个细节：如果MySQL账号只授权了localhost访问，而你连的是127.0.0.1，在MySQL的用户表里这俩其实是两个概念，容易踩坑。保险起见，本机备份时账号的Host用localhost，远程备份时单独建一个Host允许远程访问的账号。

备份账号不建议直接用root。我在生产环境习惯单独建一个专用备份账号：

CREATE USER 'backup'@'localhost' IDENTIFIED BY 'Backup@2024'; GRANT SELECT, SHOW VIEW, EVENT, TRIGGER, LOCK TABLES, PROCESS, RELOAD ON *.* TO 'backup'@'localhost'; FLUSH PRIVILEGES;

这样即使备份脚本所在机器被攻破，这个账号也只能导出数据，不能改数据。权限看着多，但mysqldump在不同场景下确实需要这些权限，比如--single-transaction需要RELOAD或至少能开启事务快照，备份触发器需要TRIGGER权限。

2.3 固定格式时间戳：绕开 %date% 的坑

很多初版备份脚本会直接拿%date%拼文件名，这是个大坑。Windows的%date%输出完全取决于系统区域设置，有的机器输出2024/03/15 周五，有的输出03/15/2024，还有的带斜杠、带空格。你用%date:~0,10%这种截取方式，换一台机器就全废了，文件名里可能出现冒号和斜杠，直接导致创建文件失败。

我的方案是用wmic OS Get LocalDateTime获取固定格式的时间。它的输出长这样：

LocalDateTime=20240315023000.000000+480

取前8位20240315是日期，第9到14位023000是时分秒，拼起来就是20240315_023000，既适合排序又不会重复。脚本里用了延迟变量展开!DT:~0,8!，因为DT是在同一个括号代码块里赋值的，普通%DT%取不到。这也是为什么文件开头要setlocal enabledelayedexpansion。

需要说明的是，Windows 11 24H2开始微软已经默认移除wmic了，所以脚本补了一个PowerShell fallback。如果wmic不可用，DT变量不会被赋值，就走PowerShellGet-Date的备份方案。两条路至少有一条能通。

2.4 mysqldump 参数逐个说清楚

核心备份命令是这一行，参数逐个看：

"%MYSQL_DUMP%" -h"%DB_HOST%" -P"%DB_PORT%" -u"%DB_USER%" -p"%DB_PASS%" --single-transaction --routines --triggers --events --default-character-set=utf8mb4 "%DB_NAME%" > "%BACKUP_FILE%" 2>> "%LOG_FILE%"

• -h主机、-P端口、-u用户、-p密码。注意-P是大写，小写-p是密码，这个拼错太常见了。
• --single-transaction是关键参数。它让 mysqldump 在 InnoDB 引擎上利用事务一致性快照做备份，备份过程中不会长时间锁表，线上业务可以继续读写。但它对 MyISAM 表无效，如果你的库里还有MyISAM表，备份时这些表会被锁住，所以备份尽量安排在低峰期跑。
• --routines --triggers --events显式导出存储过程、函数、触发器和事件计划。MySQL 5.x 默认不导出这些，很多人备份完才发现丢了存储过程，恢复的时候业务直接报错。8.x虽然默认行为有变化，但显式写出来在任何版本下都不会错。
• --default-character-set=utf8mb4防止导出SQL里的中文乱码。如果你的库本身就是utf8mb4，这行尤其重要。

再看重定向。> "%BACKUP_FILE%"把mysqldump正常输出的SQL写进备份文件；2>> "%LOG_FILE%"把标准错误追加到日志。这里有个容易翻车的习惯：很多人会写成> file 2>&1，把错误信息和SQL混在一起。mysqldump运行时的警告，比如命令行密码不安全提示、表不存在提示，一旦混进SQL文件，恢复时MySQL会把它当成无效SQL报错，整个备份就废了。所以stderr和stdout必须分开。

命令行直接带密码，每次备份日志里都会出现一条Using a password on the command line interface can be insecure.的警告，这是正常的，不是脚本错误。想彻底消除它，见第5.2节。

2.5 forfiles 的30天清理逻辑

清理用系统自带的forfiles，一行搞定：

forfiles /p "%BACKUP_DIR%" /m *.sql /d -%KEEP_DAYS% /c "cmd /c del /q @path"

• /p指定搜索目录。
• /m *.sql只匹配SQL文件，不会误删目录里其他东西。
• /d -30表示匹配修改日期早于或等于30天前的文件。也就是说，今天8月15日跑脚本，7月15日及更早的备份会被删掉，最近30天的保留。如果你希望至少保留完整的30个备份文件而不是按自然日算，那得换dir /b /o-d加循环统计，但日常场景按天清理已经够用了。
• /c "cmd /c del /q @path"对每个匹配到的文件执行删除。注意@path由forfiles自动替换成完整路径，不要在它外面再加引号，forfiles默认会给含空格的路径补引号，你再加就容易出成对的引号打架。

forfiles有个小噪音：如果没有匹配到旧文件，它会向stderr输出一句ERROR: No files found with the specified search criteria.。这不是真出错，脚本里已经把它追加到日志里了，第一次部署的人看到别慌，下次有30天前的旧文件时它就不会出现。

3. 部署到任务计划程序，让备份每天自动跑

3.1 图形界面创建任务的完整路径

脚本写得再好，不挂到任务计划程序上就只是手工工具。Win+R输入taskschd.msc打开任务计划程序，点右侧"创建任务"，主要配置如下：

常规：名称填MySQLAutoBackup，勾选"不管用户是否登录都要运行"，再勾选"使用最高权限运行"。下面"配置"下拉框选"Windows 7 / Windows Server 2008 R2"或更高版本，兼容性最稳。

触发器：点"新建"，选"按预定计划"，开始时间设成02:00，勾选"每天"。如果你的服务器凌晨有业务批处理跑，注意错开时间。还可以勾上"如果错过计划的启动时间，则立即启动任务"，这样服务器如果刚好在2点重启，开机后任务会自动补跑，不至于漏备份。

操作：点"新建"，操作选"启动程序"，程序或脚本填D:\scripts\mysql_backup.bat。这里有个细节——"起始于"一定要填bat所在目录，比如D:\scripts。虽然我们的脚本内部全部用了绝对路径，不填也能跑，但养成填的习惯，以后脚本里如果加了相对路径的引用不会翻车。

条件：如果你的机器不是插电就休眠的笔记本，把"只有在计算机使用交流电源时才启动此任务"这一项取消勾选。很多服务器实际上是台式机或工作站，不取消的话一旦UPS供电或者电源策略微妙变化，任务可能不执行。

设置：建议把"如果任务失败，请按此频率重新启动"改成"5分钟后重启，最多3次"。这样数据库瞬时抖动导致的备份失败，会自动重试几轮。

3.2 命令行一条命令创建任务

不想点GUI，用schtasks也能建：

schtasks /Create /TN "MySQLAutoBackup" /TR "D:\scripts\mysql_backup.bat" /SC DAILY /ST 02:00 /RU SYSTEM /RL HIGHEST /F

/RU SYSTEM表示以系统账户运行，这样不需要输入用户密码，也天然隐藏了黑窗口。命令行方式适合批量部署多台服务器，写个for循环就能把同样的任务推到好几台机器上。要注意的是SYSTEM账户访问本地磁盘没问题，但如果备份目录是NAS共享路径，SYSTEM访问共享目录容易遇到认证问题，那就不如GUI里指定一个有权限的账号。

3.3 运行身份与权限：最容易翻车的地方

我帮人排查计划任务不跑的案例里，十有八九是身份和权限问题。

第一种坑：任务以某个普通用户身份创建，而这个用户的密码设置了过期策略。Windows任务计划在"不管用户是否登录都要运行"模式下，会把这个用户的密码加密存储，一旦密码到期或用户改了密码，任务立刻"罢工"。解决办法是给任务指定一个长期有效的服务账号，或者用SYSTEM账户。

第二种坑：备份目录没有写权限。如果任务用SYSTEM跑，写D盘没问题；如果用普通用户跑，而备份目录是管理员创建的，普通用户可能没有写权限，mysqldump会直接报权限不足。确认方法很简单：命令行模式下手动运行一次bat，能跑通再挂计划任务。

第三种坑：黑窗口。如果你在任务的"常规"里没有勾"不管用户是否登录都要运行"，而是选了"只在用户登录时运行"，那么每天2点会弹出一个cmd窗口，一闪而过还算好，碰上卡住的备份任务窗口可能一直挂着。勾上"不管用户是否登录"不仅能解决问题，还不需要用户登录就能执行，这才是无人值守的正确姿势。

4. 备份不等于安全：验证与故障排查

4.1 两分钟读日志，确认备份真的成功

备份脚本写完不能就这么不管了，第二天早上花两分钟看一眼日志：

D:\MySQLBackup\backup.log

正常情况下末尾能看到这样的记录：

[2024/08/15 02:00:01] SUCCESS: D:\MySQLBackup\yourdb_20240815_020001.sql size=152985600 bytes [2024/08/15 02:00:03] Cleanup finished [2024/08/15 02:00:03] All done

重点看SUCCESS行里记录的文件大小。如果库平时有1GB数据，备份文件突然变成几十KB甚至0字节，那基本可以判断备份内容不完整，只是mysqldump进程没有报错退出而已。文件大小是判断备份是否异常的最快指标，我甚至建议把日志路径直接放到一个每天会瞟一眼的地方，比如桌面快捷方式或一个共享盘目录。

4.2 用 Dump completed 快速判断文件完整性

只看退出码还不够，mysqldump正常完成的SQL文件末尾有一段固定的注释：

-- Dump completed on 2024-08-15 2:00:01

可以直接用findstr验证：

findstr "Dump completed" D:\MySQLBackup\yourdb_20240815_020001.sql

有输出就说明mysqldump执行到了最后一行，文件不是半路中断的。把它加进日常排查脚本里，或者直接在命令行跑一下确认，比人眼打开几万行的SQL文件靠谱得多。注意这个文件如果已经备份到远程，验证操作要在本地没删除前做，别等30天清理后才发现上个月备份全是坏的。

4.3 恢复演练：备份能不能用，试过才知道

这是整个备份方案里最重要、也最容易被跳过的一步。备份文件没恢复过，就不能算备份成功。我第一次部署这套脚本时，第二周就把新备份恢复到一个临时库里做校验，结果发现mysqldump导出的SQL里有几条因为字符集问题恢复报错，当场堵住了隐患。

恢复演练流程很简单。先建一个临时空库：

mysql -uroot -p -e "CREATE DATABASE test_restore CHARACTER SET utf8mb4;"

再导入备份文件：

mysql -uroot -p test_restore < D:\MySQLBackup\yourdb_20240815_020001.sql

导入完成后，对比关键表的行数：

mysql -uroot -p -e "SELECT COUNT(*) FROM test_restore.orders;" mysql -uroot -p -e "SELECT COUNT(*) FROM yourdb.orders;"

两边数字一致基本就放心了。我个人的习惯是每季度干一次这事，顺便计时看看恢复速度，心里对RTO有个数。

4.4 常见故障排查表

5. 从能用走到好用：进阶优化方向

5.1 备份文件压缩，磁盘不够时的选择

SQL文本文件的压缩率很可观，同一份备份，zip或7z压完通常只有原来的20%-40%。如果磁盘空间紧张，备份完成后顺手压缩再删除原始SQL，能成倍延长保留周期。

如果你的机器装了7-Zip，脚本里加两行：

"C:\Program Files\7-Zip\7z.exe" a -tzip "%BACKUP_FILE%.zip" "%BACKUP_FILE%" -mx=5 del /q "%BACKUP_FILE%"

注意压缩后文件后缀变成了.zip，forfiles的匹配模式要从*.sql改成*.zip，否则清理逻辑永远删不到压缩包。另外压缩命令本身也可能失败，建议压缩完再检查一下zip文件是否存在，再删原文件，别压缩失败还把原始备份删了。

如果不想额外装7-Zip，也可以用Windows自带的PowerShellCompress-Archive，但处理大文件时速度和稳定性都不如7z，我一般只在临时环境里用它。

5.2 告别明文密码：defaults-extra-file

bat文件里明文写密码，总有安全顾虑，尤其是脚本放在共享目录或者多人可访问的服务器上。更稳妥的做法是建一个独立的配置文件，让mysqldump从文件里读密码，命令行不再出现任何敏感信息。

新建一个文本文件，比如C:\secure\mysql_bkp.cnf，内容：

[client] host=127.0.0.1 user=backup password=Backup@2024

然后备份命令改成：

"%MYSQL_DUMP%" --defaults-extra-file="C:\secure\mysql_bkp.cnf" --single-transaction --routines --triggers --events --default-character-set=utf8mb4 "%DB_NAME%" > "%BACKUP_FILE%" 2>> "%LOG_FILE%"

这样命令行里不再有-h/-u/-p，日志里的密码警告也消失了。接下来用icacls锁一下配置文件权限，只允许当前管理员账户读取：

icacls "C:\secure\mysql_bkp.cnf" /inheritance:r /grant:r "%USERNAME%:R"

注意如果计划任务用的是SYSTEM身份运行，SYSTEM账户也要给读取权限。这一步别漏，权限设太死反而会导致任务读取配置失败。

5.3 多库备份与异地容灾

如果一台机器上有多个业务库，不想一个个配多个任务，可以在配置区加一个库列表，用for循环逐个导出：

set "DB_NAMES=db1 db2 db3" for %%D in (%DB_NAMES%) do ( "%MYSQL_DUMP%" ... "%%D" > "%BACKUP_DIR%\%%D_%TS%.sql" 2>> "%LOG_FILE%" )

或者干脆用mysqldump自带的--databases参数，一次把所有指定库导成一个文件：

"%MYSQL_DUMP%" ... --databases db1 db2 db3 > "all_%TS%.sql"

这两种方式按需选择，分开导的好处是恢复单个库更快，合在一起导的好处是备份文件数量少、管理简单。

还有一个不能忽视的点：备份文件留在本机磁盘上，万一磁盘坏了，备份跟着一起没。所以在备份完成后加一个robocopy同步到NAS或另一台服务器，是非常值得的投资：

robocopy "D:\MySQLBackup" "\\NAS\backup\mysql" *.sql /MOV /R:2 /W:5

这里有个robocopy特有的坑：它的退出码0到7都算成功，只有大于等于8才算失败。直接在bat里if errorlevel 1判断会误报，正确写法是：

if %errorlevel% geq 8 ( echo [%date% %time%] ERROR: robocopy failed, code=!errorlevel! >> "%LOG_FILE%" )

如果你也刚好被Windows上的MySQL备份折腾过，希望这份脚本能帮你少走弯路。我至今仍保留一个习惯：每月手点一次恢复演练，毕竟备份存在的意义不是文件堆在那儿，而是真到要恢复的那一刻能拿得出来。