这类问题我又碰上了一次。CentOS 7 上备份脚本每天 2 点打包并执行 find /backup -name ‘*.tar.gz’ -mtime +6 -delete，某次真要恢复时发现最近一份是八天前的，当天的包在打包完成前就被清了。
真正麻烦的地方在于，几个原因的现象几乎一样。find 的 -mtime 按 24 小时整数天算，边界会提前一天命中当天那份；脚本先删旧再打包，备份失败时旧文件已经没了；容器里生成的包时间戳是 UTC，比本地时间早八小时，判断又偏一天。
动手时先看文件真实时间戳
ls -l --time-style=full-iso /backup | tail -8再往下改用分钟粒度精确控制
find /backup -name '*.tar.gz' -mmin +10080 -delete接着按份数保留而不是按天数
ls -1t /backup/*.tar.gz | tail -n +8 | xargs -r rm -f成功再清理的顺序写进脚本
[ -s /backup/today.tar.gz ] && ./rotate.sh怎么算真的好了，看的是同一批现象。清理后 ls 的文件数等于设定份数，最早一份的 mtime 正好是七天前，随机挑一份解包校验 md5 通过。
提醒一点。保留策略最怕“删完才发现没备上”，清理动作一定要放在备份成功之后；跨时区的机器统一按 UTC 记录，别让本地时区参与判断。拖得越久，排查成本越高，因为现场状态会被后续操作覆盖。