安全压缩旧日志的核心是“先压缩、后清理”，需精准定位闲置文件（如logrotate生成的归档文件），用find结合-mtime+7和lsof排除活跃文件，gzip -k保留原文件，分两阶段执行压缩与校验清理。

在自动化清理脚本中安全压缩超过7天的旧应用日志，核心是“先压缩、后清理”，避免直接删除导致排查无据，同时规避文件正被写入的风险。关键不在 gzip 本身，而在如何精准定位、判断和操作目标文件。

只压缩明确闲置的日志文件

gzip 不能压缩正在被进程打开写入的文件（否则可能损坏或中断服务），所以必须确保目标文件已关闭。系统日志轮转机制（如 logrotate）生成的 *.log.1、*.log.2026-07-10 等归档文件，或带 .old、.gz 后缀的旧文件，通常已不再写入，适合压缩。

• 用 find 定位修改时间 ≥7 天且不活跃的日志：find /var/log/myapp -type f -name "*.log" -mtime +7 ! -exec lsof -t {} \; -print
• 更稳妥的做法是配合轮转命名规则，例如只处理 access.log.* 或 app.log.[0-9]* 这类明确归档格式的文件
• 跳过当前主日志（如 access.log、app.log），它们大概率处于活跃状态

用 gzip -k 保留原始文件做双重保险

直接 gzip file.log 会删掉原文件，仅留 file.log.gz；而加 -k 参数可保留源文件，压缩后两者共存，便于验证内容完整性和应急回退。

• 推荐命令：find /opt/app/logs -name "*.log" -mtime +7 -exec gzip -k {} \;
• 压缩后检查：ls -lh 显示 .log 和 .log.gz 并存，大小合理（.gz 通常为原文件 10%–30%）
• 确认无误后，再用第二步脚本清理 .log（非 .gz）文件，或等满14天后再删压缩包

压缩后校验+清理分离执行

把“压缩”和“删除”拆成两个阶段，中间加入简单校验，能大幅降低误操作风险。

• 第一阶段（压缩）：find /data/logs -name "*.log" -mtime +7 -exec gzip -k {} \; 2>/dev/null
• 第二阶段（校验并清理）：find /data/logs -name "*.log.gz" -mtime +7 -exec gunzip -t {} \; -delete 2>/dev/null
• gunzip -t 用于测试压缩包完整性，校验失败则不删除，避免丢日志

配合 logrotate 实现更健壮的长期管理

单纯靠 find + gzip 是补救手段，真正安全省心的方式是让日志从源头就按规则归档压缩。

• 在 /etc/logrotate.d/myapp 中配置 compress、delaycompress、rotate 7
• 这样每天轮转时自动 gzip 旧日志，且最新一轮（.log.1）暂不压缩，方便即时查看
• 脚本只需定期清理 rotate 数量之外的 .gz 文件（如保留最近30天的压缩包）