等保2.0三级系统硬性要求本地与异地备份均不少于30天，且须基于生成时间戳、带SHA256校验、完整操作日志及180天审计日志留存，不可依赖mtime模糊清理。
三级及以上系统必须保留至少30天本地备份 + 至少30天异地备份，且不能只靠find -mtime这种模糊时间判断来清理。
等保2.0对备份保留的硬性要求是什么
等保2.0三级系统明确要求“本地备份保留不少于30天，异地备份保留不少于30天”，且需可验证、可审计。这不是建议，是测评必查项。很多DBA用find /backup -mtime +30 -delete应付，但-mtime依赖文件修改时间（mtime），而mysqldump输出的SQL文件在gzip压缩或rsync同步后mtime会被重置，导致实际保留不足30天却误删。
更关键的是：等保不认“我写了脚本”，只认“你能拿出过去30天每天一份可恢复的备份文件，并证明它没被篡改”。所以保留策略必须绑定生成时间戳、带校验、有日志记录。
Linux下安全可靠的保留策略实现方式
用日期命名+显式时间戳+校验+日志归档，替代-mtime。
- 备份文件名强制包含完整时间戳：
mysql_app_20260608_020000.sql.gz（非$(date +%Y%m%d)这种仅含日期的格式） - 用
stat -c "%y" $file或直接解析文件名提取日期，再用date -d计算天数差，避免mtime干扰 - 每次备份后生成SHA256校验文件：
sha256sum mysql_app_20260608_020000.sql.gz > mysql_app_20260608_020000.sql.gz.sha256 - 清理前写入操作日志：
echo "$(date '+%F %T') DELETE $file" >> /var/log/backup_cleanup.log
示例清理逻辑片段：
#!/bin/bash
RETENTION_DAYS=30
BACKUP_DIR="/backup/mysql"
for f in $BACKUP_DIR/*.sql.gz; do
[[ ! -f "$f" ]] && continue
ts=$(basename "$f" | grep -oE '[0-9]{8}_[0-9]{6}') # 提取20260608_020000
[[ -z "$ts" ]] && continue
days_ago=$(($(date -d "${ts:0:4}-${ts:4:2}-${ts:6:2} ${ts:9:2}:${ts:11:2}:${ts:13:2}" +%s 2>/dev/null || echo 0) - $(date +%s)))
if [ $days_ago -gt $((RETENTION_DAYS * 86400)) ]; then
rm -f "$f" "${f}.sha256"
fi
done异地备份保留必须独立于本地逻辑
本地和异地备份不能共用同一套清理脚本，也不能共享同一个时间基准。等保检查时会分别抽查两地目录，要求各自满足30天。常见错误包括：
- 用rsync把本地备份推到异地后，直接在异地服务器上跑同一份
find -mtime +30—— 这里mtime是同步时间，不是原始备份时间 - 异地目录结构没做日期隔离，所有备份混在一个文件夹里，无法按生成时间区分
- 没验证异地文件完整性，只看文件存在就认为“已备份”
正确做法：异地备份目录按/offsite/mysql/20260608/分层；每次同步后，在异地执行校验（sha256sum -c）并写入/offsite/audit.log；清理脚本也按子目录逐个处理，确保每个日期目录存活满30天才整删。
最易被忽略的一点：等保测评时，审计日志本身也必须保留180天以上，且不可被普通用户删除或覆盖。这意味着/var/log/backup_cleanup.log和/offsite/audit.log都要设为chown root:root + chmod 400，并启用chattr +a（追加只读）防止篡改。
