清理mysql过期备份需遵循“删得准、留得稳”原则：先按rpo/rto制定保留策略（如日备7天、binlog48小时、周备4周），再通过元数据而非文件名识别过期备份，最后执行dry-run→归档→校验三步安全删除，并为自动化加磁盘余量检查与通知兜底。
清理过期 MySQL 备份是释放磁盘空间、保障备份系统稳定运行的关键操作。重点不是“删得越多越好”，而是“删得准、留得稳”——保留满足恢复要求的最小必要备份集，同时避免误删或遗漏。
明确保留策略，再动手清理
没有策略的清理等于随机删库。先确认业务允许的最久恢复点（RPO）和最长恢复时间（RTO），据此设定保留规则。例如：
- 每日全量备份保留 7 天
- 每小时 binlog 归档保留 48 小时
- 每周完整备份保留 4 周（用于跨月故障回溯）
把策略写成文档，贴在运维 Wiki 或脚本头部注释里，避免换人就失效。
识别真正的“过期备份”文件
MySQL 备份命名不统一是常见坑。别只看文件名含“2023”就删，要结合生成时间与备份类型判断：
-
mysqldump 文件：用
stat -c "%y %n" *.sql查看实际修改时间 -
xtrabackup 全备目录：检查
xtrabackup_checkpoints中的backup_type = full和end_time -
binlog 文件：用
mysqlbinlog --base64-output=decode-rows -v粗略查看起始 GTID/位置，再比对主库SHOW BINARY LOGS输出
特别注意：不要仅依赖文件名中的日期字符串，有些脚本会把备份名固定为 backup.sql，实际时间藏在路径或元数据里。
安全删除三步法
删之前不验证，删完就报警。执行分三步：
-
第一步：dry-run 模拟 —— 加
--dry-run参数（如用find ... -name "*.sql" -mtime +7 -print），只列出不删除 -
第二步：归档替代直接删 —— 对临界备份（如刚好满 7 天的），先
tar -czf archive_20240510.tgz存到另一台机器或对象存储，再删本地 -
第三步：删后校验 —— 运行一次
ls -lt | head -5确认最新备份仍在；检查du -sh /backup磁盘使用率是否明显下降
自动化清理要带兜底机制
定时任务（如 cron）清理很方便，但必须加防护：
- 脚本开头加磁盘余量检查：
df /backup | awk 'NR==2 {if ($5+0 > 90) {exit 1}}' - 每次清理后发简短通知到钉钉/企业微信，含删除数量、释放空间、保留最新备份名
- 保留最近 3 次清理日志，路径如
/var/log/mysql_backup_purge_*.log，方便追溯
自动清理不是设完 cron 就完事，而是让它“聪明地停在安全线以内”。
