用cron调度mysqldump脚本最稳，需用绝对路径+~/.my.cnf存密（chmod 600），避免环境差异导致命令未找到、认证失败或备份为空；crontab时间格式为“分 时 日 月 周”，注意时区；脚本须含find清理逻辑，先-test再-delete防误删。
直接上结论：用 cron 调度 mysqldump 脚本是最稳、最轻量、最可控的方式，不依赖面板、不引入额外服务，适合生产环境长期运行。
为什么不能直接在 crontab 里写 mysqldump 命令？
因为 cron 的执行环境和你登录终端完全不同——它没有你的 $PATH、不加载 ~/.bashrc、也不读取 MySQL 配置文件。常见现象包括：
-
mysqldump: command not found（cron找不到命令） -
Access denied for user 'root'@'localhost'（密码没传进去或认证失败） - 备份文件为空，但日志里没报错（压缩或重定向被静默吞掉）
解决办法只有两个：所有命令写绝对路径，认证改用 ~/.my.cnf（而不是 -u -p 参数）。
如何安全地传数据库账号密码？
明文写在脚本里（比如 -uroot -p123456）会被 ps aux 看见，也容易误提交到 Git。正确做法是用 MySQL 的配置文件机制：
创建 /root/.my.cnf（如果用 root 运行 cron）：
[mysqldump] user = backup_user password = your_strong_password
然后 chmod 600 /root/.my.cnf ——这步漏掉会导致 mysqldump 拒绝读取该文件。
脚本里就不用再带 -u/-p 参数了，直接：/usr/bin/mysqldump mydb > /backup/mydb_$(date +%Y%m%d).sql
crontab 时间格式写错会导致“看似生效实则没跑”
常见错误是把「每天凌晨 2 点」写成 0 2 * * * （正确），却误写为 2 0 * * * （这是每天凌晨 0:02）。cron 字段顺序是：
分 时 日 月 周 命令
另外注意：cron 默认用系统本地时区，如果你服务器时区是 UTC，而你想按北京时间 2 点执行，就得换算成 UTC 时间（即 18:00），或者显式设置 TZ=Asia/Shanghai 在脚本开头。
调试建议：先设成每 5 分钟跑一次（*/5 * * * * ），确认日志有输出、文件生成成功，再改回真实时间。
备份脚本必须自带清理逻辑，否则磁盘迟早爆掉
没人会手动删旧备份。脚本末尾加一行清理是底线操作：
find /backup -name "mydb_*.sql*" -mtime +7 -delete
注意三点：
-
-mtime +7表示“修改时间超过 7 天”，不是“创建时间”；mysqldump输出的文件修改时间 ≈ 备份完成时间，基本可用 - 如果备份用了
gzip，记得把通配符改成"mydb_*.sql.gz"，否则可能误删日志或其他文件 - 加
-print先试运行（如find ... -mtime +7 -print），确认列出的确实是该删的文件，再加-delete
真正容易被忽略的是：find 不处理硬链接或符号链接，如果备份目录里混入了其他来源的文件，-delete 可能误伤——所以备份目录最好专用于此，别手抖往里扔东西。
