备份脚本中禁止明文写密码，应使用权限为600的~/.my.cnf配置文件存储凭证；crontab时间格式须遵循“分 时 日 月 周”顺序，避免误配导致高频执行；备份需压缩、轮转并验证完整性。

备份脚本里别直接写密码，mysqldump 会暴露在进程列表里

你执行 mysqldump -u root -p123456 db_name，别人用 ps aux | grep mysqldump 就能看见密码。这不是理论风险，是真实发生过的线上事故。

正确做法是用配置文件隔离凭证：

• 新建 ~/.my.cnf，权限设为 600（chmod 600 ~/.my.cnf）
• 内容只写：

  [client]
  user = backup_user
  password = your_secure_password

• 调用时省略用户和密码：mysqldump --defaults-extra-file=~/.my.cnf db_name
• 确保该文件不属于 root 或其他共享账户，且不在版本控制中

crontab 时间表达式写错，备份就永远不跑

常见错误是把「每小时 15 分执行」写成 15 * * * *（实际是每小时第 15 分钟），但误写成 * 15 * * * 就变成每月 15 号每天每分钟跑一次——磁盘瞬间告急。

实操建议：

• 用 crontab -e 编辑，别手写到系统级 /etc/crontab，容易权限混乱
• 时间字段顺序固定：分 时 日 月 周，记不住就贴张便签在显示器边
• 加日志重定向，比如：0 2 * * * /backup/db_backup.sh >> /var/log/db_backup.log 2>&1
• 测试时先用 */5 * * * *（每 5 分钟）验证脚本逻辑，确认无误再切正式周期

备份文件不压缩、不轮转，三个月后 /backup 目录占满磁盘

裸 SQL 文件体积通常是数据库实际大小的 1.2–1.8 倍；不处理的话，一周就能积攒几十 GB。

必须做的三件事：

• 用 gzip 压缩：mysqldump ... | gzip > /backup/db_$(date +\%Y\%m\%d_\%H\%M).sql.gz
• 保留最近 7 天：用 find /backup -name "db_*.sql.gz" -mtime +7 -delete
• 检查压缩后文件是否有效：gzip -t /backup/latest.sql.gz，失败就发邮件告警（可用 mail -s "Backup broken" admin@example.com）

跨服务器备份时，ssh 密钥没配好，rsync 就卡住不动

脚本里写 rsync -avz /backup/ user@backup-server:/data/，结果 crontab 下完全没反应——因为 cron 环境不加载 ~/.bashrc，导致 ssh agent 不可用，密钥路径或 SSH_AUTH_SOCK 找不到。

解决路径很窄，只有两条靠谱的：

• 用 -i 显式指定私钥：rsync -avz -e "ssh -i /home/backup/.ssh/id_rsa" /backup/ user@backup-server:/data/
• 或者改用免交互的 sshpass（仅限内网可信环境）：sshpass -f /home/backup/.ssh/passfile rsync -avz ...，但要确保 .ssh/passfile 权限为 600
• 绝对不要在命令行里写明文密码，rsync 的 --password-file 对 SSH 无效，那是给 rsync daemon 用的

备份最麻烦的从来不是写脚本，而是某天凌晨三点发现上个月的归档根本解不开——gzip -t 那一行，很多人删掉图省事，结果真出问题时连后悔都来不及。