可靠的mysql备份需封装脚本并正确配置crontab：设置变量、创建目录、mysqldump加–single-transaction、压缩与清理旧文件；注意权限、PATH、密码安全（用~/.my.cnf）、日志记录及非交互环境测试。

用 crontab 定时备份 MySQL 数据库，核心是写好备份脚本 + 正确配置定时任务。关键点在于权限、路径、环境变量和错误处理，很多失败是因为脚本在 cron 环境下执行时找不到命令或连不上数据库。

写一个可靠的 MySQL 备份脚本

不要把 mysqldump 命令直接塞进 crontab 里，先封装成 shell 脚本，方便调试和复用：

• 脚本示例（保存为 /home/user/bin/backup_mysql.sh）：

#!/bin/bash # 设置变量（按需修改） DB_USER="root" DB_PASS="your_password" DB_NAME="myapp" BACKUP_DIR="/home/user/backups/mysql" date=$(date +%Y%m%d_%H%M%S) 
创建备份目录（如果不存在）
mkdir -p "$BACKUP_DIR"
执行备份（加 --single-transaction 避免锁表，适合 InnoDB）
mysqldump -u"$DB_USER" -p"$DB_PASS" --single-transaction "$DB_NAME" > "$BACKUP_DIR/${DBNAME}$DATE.sql"
可选：压缩备份文件节省空间
gzip "$BACKUP_DIR/${DBNAME}$DATE.sql"
可选：只保留最近 7 天的备份
find "$BACKUP_DIR" -name "${DBNAME}*.sql.gz" -mtime +7 -delete

• 给脚本添加执行权限：chmod +x /home/user/bin/backup_mysql.sh
• 手动运行一次测试：/home/user/bin/backup_mysql.sh，确认生成文件且无报错
• 注意：生产环境建议用配置文件存密码（如 ~/.my.cnf），避免密码明文出现在脚本或进程列表中

配置 crontab 定时任务

用当前用户（如非 root，推荐用数据库操作用户）编辑定时任务：

• 运行 crontab -e
• 添加一行（例如每天凌晨 2:30 执行）：

30 2 * * * /home/user/bin/backup_mysql.sh >> /home/user/logs/backup_mysql.log 2>&1

• >> 把标准输出追加到日志；2>&1 把错误也一起记录，便于排查
• 确保 cron 能找到 mysqldump：可在脚本开头加上 PATH=/usr/local/bin:/usr/bin:/bin，或使用绝对路径（如 /usr/bin/mysqldump）
• 避免使用 % 符号（cron 中有特殊含义），如需日期格式，用 $(date +%Y%m%d) 并转义

验证与排错要点

很多备份“看似运行了”，实则静默失败。重点关注这几项：

• 检查 cron 日志：sudo tail -f /var/log/syslog | grep CRON（ubuntu/debian）或 sudo journalctl -u cron -f
• 确认脚本中所有命令路径正确（cron 默认 PATH 很窄，which mysqldump 查看实际路径）
• 测试脚本是否能在非交互式环境下运行（env -i /bin/bash --noprofile --norc /home/user/bin/backup_mysql.sh）
• 如果用 root 的 crontab 备份其他用户的数据库，注意 ~/.my.cnf 权限必须是 600，且属主匹配
• 定期抽查备份文件是否可解压、SQL 文件是否以 CREATE table 开头，不是空文件或报错内容

进阶建议

提升稳定性和运维效率的小技巧：

• 备份前加锁检测或标记（如 touch backup.lock），防止上一次没跑完就启动新任务
• 备份完成后发邮件或写入监控系统（如用 curl 推送状态）
• 对多库场景，用 mysql -Nse "SHOW DATABASES" 动态获取库名，循环备份
• 考虑用 mydumper 替代 mysqldump（支持多线程、更细粒度控制），适合大库