logrotate 无 minage 配置项，需用 maxage（设日志驻留下限）与 dateext/dateformat（增强可审计性）组合实现“至少保留 n 天”；配合 sharedscripts 和巡检确保合规。
minage 不是 logrotate 的有效配置项 —— 它并不存在。你可能混淆了 maxage（最大保留天数）或 olddir、dateext 等参数。logrotate 没有 minage 机制，也不提供“强制日志至少驻留 X 天”的最小时间保障功能。
真正能确保日志在本地驻留最短时长的，是组合使用以下两个核心参数，并理解它们的执行逻辑：
✅ maxage：按时间兜底清理，防止过早删除
maxage N 表示：任何轮转后的归档日志，只要其最后修改时间距今超过 N 天，就会被无条件删除（无论 rotate 数量是否用完）。
它不控制“最早能删哪天”，而是设定“最晚必须删哪天”——这恰恰构成了日志驻留的硬性下限保障。
例如：
/var/log/app.log {
daily
rotate 30
maxage 90
compress
missingok
notifempty
}
-
rotate 30：最多保留 30 个归档文件（比如app.log.1到app.log.30.gz） -
maxage 90：所有归档文件若修改时间 ≥ 90 天前，立即删除
⚠️ 关键点：logrotate 每次运行时，同时检查 rotate 和 maxage。只要任一条件不满足（文件数超 30 或 年龄超 90 天），该归档即被清理。
→ 所以，一个日志归档实际存活时间 = min(它在 rotate 队列中的位置, 它的文件年龄)。
但 maxage 是绝对阈值：哪怕只保留了 1 个文件，只要它满 90 天，也会被删；反之，只要没满 90 天，哪怕 rotate 30 已满，它也一定还在。
✅ 这就实现了“至少保留 90 天”的合规底线：
- 新生成的归档，从创建当天起算，必须活满整整 90 天才会被允许删除；
- 即使磁盘紧张、
rotate值调小，maxage仍会拦截过早清理。
✅ dateext + dateformat：让归档可追溯、可审计
仅靠 maxage 还不够 —— 你需要确认哪些文件真正在“90 天内”。默认归档名如 app.log.1、app.log.2.gz 无法直接看出日期，难以验证合规性。
启用时间后缀：
dateext dateformat -%Y%m%d
→ 归档变成 app.log-20260401.gz、app.log-20260402.gz…
→ 可直接用 ls -lt /var/log/app.log-* | head -n 5 查看最新归档日期；
→ 用 find /var/log -name "app.log-*.gz" -mtime +90 快速验证有无违规残留（应为空）；
→ 审计时，一眼可证：最老的有效归档日期 ≥ 当前日期 - 90 天。
✅ 配合 sharedscripts 和 postrotate 确保服务不丢日志
某些服务（如 nginx、rsyslog）需在轮转后重载或发信号，否则新日志可能写入旧文件或丢失。若轮转失败，会导致归档缺失、时间断层，间接破坏 maxage 的连续性保障。
正确做法：
sharedscripts
postrotate
# 根据服务选择对应命令，确保新日志写入新文件
systemctl kill --signal=USR1 rsyslog.service 2>/dev/null || true
endscript
✅ 验证与巡检（合规落地关键）
- 查看上次轮转记录：
cat /var/lib/logrotate/status | grep "app.log"→ 确认最近轮转时间是否规律（如每天一次） - 手动触发测试（不删不改，只模拟）：
logrotate -d /etc/logrotate.d/app→ 检查输出中是否列出预期的maxage删除动作 - 自动化校验脚本（建议加入每日巡检）：
# 检查最老归档是否 ≥ 90 天前 OLDEST=$(ls -t /var/log/app.log-*.gz 2>/dev/null | tail -1) if [ -n "$OLDEST" ]; then DAYS_OLD=$(($(date -d "$(stat -c '%y' "$OLDEST" | cut -d' ' -f1)" +%s)
不复杂但容易忽略
