用 find -mtime 配合 cron 清理旧备份最可靠：避免 ls | grep 的兼容性问题，加 -maxdepth 1 防误删，首次用 -print 验证，-delete 前加 sleep 随机延迟防 I/O 冲突，注意时区、rsync 安全参数及跨卷权限风险。
用 find + -mtime 配合 cron 清理旧备份，别用 ls | grep
直接用 find 按修改时间删文件，是唯一靠谱做法。用 ls 列表再管道过滤，不仅慢（尤其目录大时），还会因文件名含空格、换行或特殊字符导致误删或跳过。
-
find /backup -name "*.tar.gz" -mtime +7 -delete：删 7 天前的压缩包（注意-mtime +7表示「超过 7×24 小时」，不是「7 天整」） - 加
-maxdepth 1防止误入子目录（比如/backup/2024-01/下还有嵌套备份） - 首次运行前务必把
-delete换成-print看下实际匹配哪些文件，确认路径和时间逻辑无误 - 避免用
-atime（访问时间），某些挂载选项（如noatime）会让它失效或不准
crontab 时间设置要避开业务高峰，且加随机延迟
所有服务器在同一秒触发清理，可能瞬间打满 I/O 或触发限速策略，尤其在共享存储或低配 VPS 上容易丢包、SSH 卡顿。
- 不要写
0 2 * * *这种整点任务；改用15 2 * * *或更稳妥的17-23 2 * * *（2:17–2:23 随机某秒） - 在命令前加
sleep $((RANDOM % 300))，让每次执行延后 0–300 秒，分散压力 - 检查 crontab 时区：
grep "TZ=" /etc/crontab或crontab -l里是否显式声明了TZ=UTC，否则可能和系统时间不一致，导致误删
rsync 同步备份时加 --delete-after 和 --delay-updates
如果清理动作发生在 rsync 推送新备份之后，但又没等同步真正完成就删旧文件，可能造成「新备份未写完就被删旧备份」的空窗风险，引发恢复失败。
- 用
--delete-after确保先传完所有文件，再删远端多余项；比--delete-before更安全 - 加
--delay-updates把所有临时文件先写到隐藏目录（如.~tmp~），全部成功后再原子性重命名，避免网络中断导致远端残留半截文件 - 别省略
--partial—— 断点续传能显著降低重复传输带来的延迟和丢包感知
监控清理是否真生效，而不是只看 cron 日志
crontab 显示“已运行”不等于清理成功。常见失败包括：磁盘满导致 find -delete 权限被拒、NFS 挂载点临时不可写、mtime 因备份脚本用了 touch -d 被篡改。
- 在清理命令后加一行：
&& find /backup -name "*.tar.gz" -mtime +7 | wc -l >> /var/log/backup-cleanup.log，记录每次还剩多少超龄文件 - 用
df -h /backup定期采样，和清理日志对齐——如果日志说删了 5G，但df没变化，大概率删的是软链接或挂载子目录 - 特别注意 LVM 快照、btrfs 子卷、或 overlayfs 场景：
find可能跨卷匹配，但-delete在只读快照上会静默失败
真正麻烦的不是脚本写不对，而是清理动作混在多个挂载点、快照层或容器卷里，find 看得见，rm 却没权限——得先 mount | grep backup 确认路径归属。
