find + cron 是最稳的生产级备份清理方案：无需额外工具，find 自带精准时间判断（-mtime +30 表示严格大于30天），cron 保障定时执行；务必先用 -print 测试、加 -maxdepth 1 和 -name 限定范围、用绝对路径写入 crontab 并重定向日志。
用 find + cron 是最稳的组合
直接上生产环境验证过的做法：不用额外装工具，不依赖脚本解释器兼容性，find 自带时间判断，cron 保证定时执行。其他方案（比如用 logrotate 或自写 Python 脚本）在备份清理场景下反而容易多一层出错点。
find -mtime +30 的真实含义和常见误解
-mtime +30 不是“30 天及更早”，而是“严格大于 30 天”——即最后修改时间在 30×24 小时之前。例如今天是 7 月 8 日，它匹配的是 6 月 7 日 01:00 之前的文件，不包含 6 月 7 日当天的文件。
- 误用
-mtime 30（无符号）会只匹配恰好 30 天整的文件，基本找不到 - 想按创建时间删？
-printf '%B@' | awk可行但不通用，ext4 默认不存 birth time，-mtime最可靠 - 测试阶段必须先用
-print，别一上来就-delete：find /backup -type f -mtime +30 -name "*.tar.gz" -print
加 -maxdepth 1 和 -name 防止误删
备份目录里混着子目录或临时文件？不加限定，find 会递归进所有层级，可能删掉不该动的配置或日志。
-
-maxdepth 1锁定只查一级文件，跳过子目录（如/backup/20240601/下的文件不会被扫到） -
-name "db_backup_*.tar.gz"或-name "*.sql.gz"明确文件模式，避免误伤同目录下的.pid或.lock - 如果备份是目录而非文件，把
-type f换成-type d，但要确认该目录下没嵌套重要数据
写进 cron 时的三个硬性检查点
很多故障不是命令写错，而是执行上下文不对。root 的 crontab、PATH、当前工作目录都和你手动执行时不同。
- 用
sudo crontab -e编辑 root 的任务（备份文件通常属 root） - 命令行开头补全绝对路径：
/usr/bin/find而非find（crontab 默认 PATH 很窄） - 重定向日志必须用完整路径：
>> /var/log/backup_cleanup.log 2>&1，否则可能写到 root 家目录下且没权限 - 示例安全写法：
15 2 * * * /usr/bin/find /backup -maxdepth 1 -type f -mtime +30 -name "backup_*.tgz" -delete >> /var/log/backup_cleanup.log 2>&1
真正麻烦的不是写命令，而是备份命名不规范、路径不隔离、没提前测试 —— 这些问题在 -print 阶段暴露不出来，得等 -delete 执行后才发现删错了。建议第一次上线前，用 touch 创建几个模拟过期文件跑三遍测试。
