备份清理不能只靠find+mtime，因勒索软件可篡改crontab提权删除，且mtime易受重试/中断影响错乱；应以最小权限专用用户运行，按文件名时间戳识别，加保留清单、完整性校验及隔离删除机制。
备份文件清理为什么不能只靠 find + mtime
因为勒索软件常利用定时任务提权后批量删除或加密备份，单纯用 find /backup -type f -mtime +7 -delete 有两大风险：一是执行用户权限过高（如 root），一旦 crontab 被篡改就成帮凶；二是 mtime 受文件修改影响，备份脚本重试、中断续传会导致时间戳错乱，误删未完成的备份。
实操建议：
- 清理命令必须以最低权限运行——用专用系统用户（如
backupclean），仅对备份目录有r-x权限，禁止写和执行 - 优先按文件名中的时间戳识别，而非
mtime。例如备份文件命名规范为mysql_full_20240520_020001.sql.gz，用date解析比mtime可靠得多 - 加一层“保留清单”机制：先生成待删列表到临时文件，人工抽检后再执行真正删除
MySQL 备份清理脚本必须校验 mysqldump 完整性再删
直接删备份前不验证，等于把损坏备份当真货存着，等真出事才发现全是空文件或截断内容。常见错误现象是 mysqldump 因锁表失败、连接中断、磁盘满提前退出，但返回码仍是 0（尤其老版本 MySQL）。
实操建议：
- 每次备份后立刻用
gzip -t检查压缩完整性，再用head -c 100看开头是否有CREATE DATABASE或-- MySQL dump标识 - 清理脚本中加入校验逻辑：对每个待删文件，先
zcat $f 2>/dev/null | head -n 1 | grep -q "MySQL dump"，不匹配则跳过删除并告警 - 避免用
rm -f无差别删——改用mv $f /backup/trash/隔离 24 小时，确认无误再清空/backup/trash/
crontab 清理任务被勒索软件劫持的典型特征
攻击者植入的恶意定时任务往往藏在非标准位置，或伪装成正常备份任务。常见错误现象包括：crontab 中出现异常路径（如 /tmp/.X11-unix/）、调用 curl 或 wget 下载二进制、执行 chmod +x && ./ 组合命令。
实操建议：
- 只允许从
/etc/cron.d/加载清理任务，禁用用户级crontab -e；所有任务文件属主设为root:root，权限0644 - 清理脚本自身禁止网络调用、禁止
eval、禁止读取环境变量以外的任意配置——所有路径、保留天数必须硬编码或从只读配置文件（如/etc/backup-clean.conf）读取 - 每天用
crontab -l | md5sum记录指纹，配合inotifywait监控/etc/cron.d/目录变更
MySQL 物理备份（xtrabackup）清理要绕开 innobackupex 的坑
innobackupex 已废弃，但很多线上脚本还在用，它生成的备份目录里含 xtrabackup_checkpoints，而新版 xbcloud 或手动清理时若忽略该文件，可能误判备份状态为“未完成”，导致不该删的全删了。
实操建议：
- 物理备份清理前必查
cat $backup_dir/xtrabackup_checkpoints | grep -q "backup_type = full"和"state = completed" - 不要用
find ... -name "2024*"粗暴匹配目录名——xtrabackup默认按秒级时间戳建目录（如2024-05-20_02-00-01），注意连字符与下划线差异 - 删除整个备份目录前，先
rm -rf $dir/{xtrabackup_logfile,mysql-bin.*}（日志文件可单独删），再删主目录，降低 I/O 峰值压力
真正难的不是写个能删文件的脚本，而是让清理行为本身不成为攻击面——权限隔离、输入可控、状态可验，这三件事漏掉任何一环，自动清理就从保险丝变成引信。
