Cron执行mysqldump备份脚本异常：生成空MySQL备份文件

我来帮你排查这个头疼的问题——这种Cron执行脚本和命令行执行结果不一致的情况，我碰到过好多次，大概率是Cron的环境特殊性或者脚本里的细节没处理到位，咱们一步步来解决：

1. 强制使用mysqldump的绝对路径 #

Cron的环境变量PATH即使你手动设置了，有时候还是会因为执行上下文的问题找不到正确的二进制文件。你先在命令行执行下面的命令找到mysqldump的绝对路径：

which mysqldump

比如会得到/usr/bin/mysqldump，然后把脚本里所有的mysqldump替换成这个绝对路径。这一步能解决90%的“命令行能跑Cron跑不了”的基础问题。

2. 检查MySQL登录的认证配置 #

如果你的脚本是依赖~/.my.cnf这个配置文件来免密登录MySQL的，那Cron执行时可能找不到这个文件：因为Cron的HOME目录不一定和你登录用户的HOME一致，或者配置文件的权限太开放（MySQL会拒绝读取权限大于600的配置文件）。

解决办法二选一：

• 在脚本里显式指定配置文件的绝对路径，比如：

  /usr/bin/mysqldump --defaults-extra-file=/home/your_username/.my.cnf your_database_name
  

• 或者直接在脚本里带上MySQL的用户名和密码（不推荐明文密码，但如果是私人服务器可以临时测试）：

  /usr/bin/mysqldump -u your_db_user -p'your_db_password' your_database_name
  

注意：如果用配置文件，一定要把它的权限改成chmod 600 /home/your_username/.my.cnf，避免被其他用户读取。

3. 捕获错误输出，定位具体问题 #

Cron执行时的错误信息默认会发送到系统邮件，但很多人没配置邮件接收，导致看不到失败原因。你可以在脚本的备份命令里加上错误日志重定向，这样就能直接看到哪里出问题了：
修改后的脚本片段示例：

#!/bin/sh
now="$(date +'%d_%m_%Y_%H_%M_%S')"
filename="db_backup_$now".gz
backupfolder="/mybackup/path"
# 先确保备份目录存在，避免目录不存在导致失败
mkdir -p "$backupfolder"
# 使用绝对路径的mysqldump，并重定向错误到日志文件
/usr/bin/mysqldump --defaults-extra-file=/home/your_username/.my.cnf your_database | gzip > "$backupfolder/$filename" 2>> /var/log/db_backup_error.log

之后查看/var/log/db_backup_error.log，就能看到比如“认证失败”“权限不足”“数据库不存在”这类具体错误了。

4. 确认Cron的执行用户权限 #

你在命令行执行脚本没问题，但Cron可能是用普通用户执行的，这个用户可能没有写入备份目录的权限，或者没有访问MySQL的权限。你可以：

• 用sudo crontab -e编辑root用户的Cron任务，确保执行权限足够
• 或者在Cron任务里指定用户，比如：

  0 2 * * * root /path/to/your/backup_script.sh
  

5. 最后检查脚本的可执行权限 #

虽然你说命令行能执行，但还是确认下脚本有可执行权限：

chmod +x /path/to/your/backup_script.sh

按照上面的步骤排查，基本就能解决空备份文件的问题了。

内容的提问来源于stack exchange，提问作者LiquidLunch