最轻量可控的MySQL备份方案是mysqldump+crontab，但90%失败源于环境变量、权限、路径或配置未生效；需用which查mysqldump全路径、显式指定配置文件、用绝对路径写日志并预创建、脚本中加时间戳和退出码判断、压缩走管道、旧备份用date计算日期精准清理，并务必手动验证备份有效性。
直接用 mysqldump + crontab 是最轻量、最可控的方案，但90%的失败不是因为命令写错，而是环境变量、权限、路径或配置文件没生效。
crontab 里 mysqldump 不执行？先查这三件事
crontab 默认不加载用户 shell 环境，mysqldump 找不到、密码读不到、日志写不进，都是静默失败。
- 必须用
which mysqldump查准全路径（常见是/usr/bin/mysqldump），脚本里不能只写mysqldump -
~/.my.cnf在 cron 下无效——要么改用--defaults-extra-file=/root/.backup.cnf显式指定，要么把账号密码明写进命令（仅限测试环境） - 日志路径要绝对路径，且确保
crond运行用户（通常是root）有写权限，比如/var/log/mysql_backup.log要提前touch并chown root:root
备份脚本必须带时间戳和退出码判断
不加时间戳 = 每天覆盖，出问题根本没法回溯；不判断 $? = 备份失败了你也看不见。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 时间格式推荐
$(date +\%Y\%m\%d_\%H\%M)（注意%要转义），避免空格和特殊字符 - 压缩必须走管道：
mysqldump ... | gzip > backup.sql.gz，别分两步写，中间 .sql 文件可能被清理或占满磁盘 - 加
if [ $? -ne 0 ]; then echo "ERROR" >> log; exit 1; fi，让 cron 能捕获失败并邮件告警（如果配了 MAILTO）
旧备份自动清理别只靠 find -mtime
find ... -mtime +7 看似简单，但实际会漏删、多删——它按文件修改时间算，而备份文件创建后可能被 touch 过，或者时区导致计算偏差。
- 更可靠的做法是用
date -d "7 days ago" +%Y%m%d生成基准日期，再用find ... -name "*${BASE_DATE}*" -delete - 删除前加
echo预演：比如find $BACKUP_DIR -name "*.sql.gz" | grep -E "$(date -d '15 days ago' +%Y%m%d)"，确认匹配逻辑对了再加-delete - 清理动作本身也要记日志，否则哪天删多了你都不知道是谁干的
真正麻烦的从来不是“怎么写备份脚本”，而是“怎么证明它每次都能成功”。建议第一次部署后，手动触发脚本，立刻检查输出、文件名、压缩包能否解压、日志有没有 ERROR 字样——这些细节不验证，定时任务跑半年也可能是假备份。
