用~/.my.cnf存储密码更安全，需设权限600并确保属主一致；明文密码在脚本中会暴露于ps、history等，等同裸奔；后续mysqldump可省略-u/-p参数。
备份脚本里密码别明文写，用~/.my.cnf更安全
明文密码在脚本里等于裸奔——ps aux、进程日志、甚至history都能看到。正确做法是把认证信息单独存进~/.my.cnf，并设权限600：
cat > ~/.my.cnf <p>后续脚本里直接调<code>mysqldump</code>就不需要<code>-u -p</code>参数了，也避免<code>mysqldump</code>提示输入密码卡住。</p>
- 必须确保运行脚本的用户和
~/.my.cnf属主一致，否则读不到 -
mysqldump默认读$HOME/.my.cnf，不能用sudo切用户后路径错乱 - 别在
/etc/my.cnf里配，那是全局配置，容易被其他服务误用
find -mtime +N删备份时，N=6还是+7？看你要“留几天”
-mtime +7不是“超过7天”，而是“修改时间 ≥ 168 小时前”，即从今天 00:00 开始往前推 7 整天。如果你希望保留最近 7 天的备份（含今天），该用-mtime +6——它删的是 7 天前（含）及更早的文件。
- 假设今天是 2026-07-01，备份生成于 02:00，那它到 2026-07-02 02:00 才满足
-mtime +1 - 所以
-mtime +6实际保留的是 2026-06-26 00:00 之后的所有备份 - 先加
-print测试：/usr/bin/find /backup/mysql -name "*.sql.gz" -type f -mtime +6 -print - crontab 中务必写绝对路径：
/usr/bin/find，否则 cron 环境找不到命令
清理前先校验备份完整性，否则删掉的是“假备份”
备份脚本执行成功 ≠ 文件可用。mysqldump因锁表失败、磁盘满、连接中断可能生成空或截断文件，但返回码仍是 0。清理脚本若不检查，就等于定期销毁唯一副本。
- 每个待删文件先跑
zcat "$f" 2>/dev/null | head -n 1 | grep -q "MySQL dump"，不匹配就跳过删除并记日志 - 压缩包本身也要校验：
gzip -t "$f"，损坏的 gzip 文件zcat会静默失败 - 别用
rm -f直接删，改用mv "$f" /backup/trash/隔离 24 小时，确认无误再清空/backup/trash/ - 清理脚本运行用户权限要最小化，比如专用用户
backupclean，仅对备份目录有r-x，无写权限
备份目录混着临时文件？-type f和! -name必须加上
生产环境备份目录常有.part、.tmp、锁文件或二进制日志（如mysql-bin.000001），直接find ... -delete可能删掉正在写的备份或非备份文件。
- 强制限定普通文件：
-type f，排除目录、socket、设备节点 - 精确匹配扩展名：
-name "*.sql.gz" -o -name "*.xbstream" -o -name "*.zst"，避免误删 binlog - 排除临时文件：
! -name "*.part" ! -name "*.tmp" ! -name "lock.*" - 如果备份脚本生成带日期子目录（如
/backup/mysql/20260701/），清理时别用-delete删目录，改用-exec rm -rf {} \;并加-depth防误删父目录
真正麻烦的不是写错一行命令，而是删完才发现某个.part文件其实刚写完一半，或者mysql-bin被当成备份删了——这种事没法回滚。
