靠谱的备份清理脚本需用 find 基于文件真实修改时间（-mtime +7）删除，加 -maxdepth 1 和 -type f 防误删，先测试再执行；crontab 需显式设 SHELL=/bin/bash、用绝对路径、重定向日志，并模拟环境测试。

直接用 crontab 定时删备份，关键不是“加一行就完事”，而是让删除动作稳定、安全、可验证。重点在脚本健壮性、时间判断准确性和执行环境可控。

写一个靠谱的清理脚本

别依赖文件名里的日期，用文件真实修改时间判断最可靠：

• 用 find /backup -name "*.sql.gz" -mtime +7 -delete 删除 7 天前修改的备份文件（注意：-mtime +7 指“超过 168 小时”，即第 8 天起）
• 先测试再删除：把 -delete 换成 -ls 或 -print，确认列出的是你真想删的文件
• 加 -maxdepth 1 防止误入子目录；加 -type f 确保只处理普通文件
• 脚本开头必须写 #!/bin/bash，所有命令用绝对路径，比如 /usr/bin/find、/bin/rm

让 crontab 正确执行脚本

crontab 默认用 /bin/sh，PATH 极窄（通常只有 /usr/bin:/bin），容易找不到命令或解释器：

• 在 crontab -e 顶部显式声明：SHELL=/bin/bash
• 任务行完整写法示例：0 2 * * * /bin/bash /opt/scripts/clean_backup.sh >> /var/log/clean.log 2>&1
• 务必重定向输出，否则失败无声；日志能帮你快速定位权限、路径、命令缺失等问题
• 模拟 cron 环境测试脚本：env -i /bin/bash --noprofile --norc /opt/scripts/clean_backup.sh

时间设置和防误删要点

时间写错或逻辑松散，可能导致不执行、乱删、删太快：

• 确认系统时区：timedatectl status | grep "Time zone"，非本地时区要调整 cron 时间
• 避免同时指定具体“日”和“星期几”（如 0 2 1 * 1），整行会被忽略
• 若需保留最近 N 个备份（而非按天），改用 ls -t | tail -n +$((N+1)) | xargs rm -f 类逻辑，更直观可控
• 删除前加 echo "Would delete: $(find ... -print)" 到日志，留痕可追溯

权限与上下文别踩坑

谁运行脚本，决定了它能删什么：

• 用 crontab -e 编辑的是当前用户 crontab，脚本以该用户身份运行；若备份文件属 root，而你是普通用户，rm 会静默失败
• 要么用 sudo crontab -e（对应 root 权限），要么确保备份目录和文件权限允许当前用户操作
• 脚本里涉及数据库导出或压缩的，也要检查对应命令（如 mysqldump、gzip）是否存在且可访问