Logrotate 无 rotate-max 参数，超长周期日志维护需组合 dateext、maxage、dateformat 及外部脚本：用 dateext+maxage 按时间保留，find 定时清理，冷备归档至外部存储，并规避命名、权限与时间精度陷阱。
Logrotate 本身没有 rotate-max 这个原生命令参数，你提到的“Rotate-Max”很可能是对 maxage、rotate 或自定义保留策略的混淆。Linux 中实现**超长周期（如数年）日志的历史维护**，关键不是靠某个单一参数，而是组合使用 rotate、maxage、dateext、dateformat 和外部归档逻辑，同时规避 Logrotate 默认按“轮转次数”而非“时间跨度”清理的局限。
用 dateext + maxage 实现基于时间的长期保留
Logrotate 默认按轮转次数（rotate N）删除旧文件，这对超长周期不友好。改用时间维度更可靠：
-
dateext：启用日期后缀（如app.log-20241201），让文件名自带时间信息 -
dateformat -%Y%m%d：指定日期格式（支持%Y%m%d%H精确到小时） -
maxage 1095：保留最近 3 年（1095 天）内生成的归档文件（注意：它只检查文件 mtime，且仅对带日期后缀的文件生效） - 务必配合
create或copytruncate，确保新日志可写
突破 maxage 的 mtime 限制：用 find + 定时任务做二次清理
maxage 依赖文件修改时间（mtime），但日志归档后可能被 touch、scp 或备份工具更改，导致误删。超长周期下更稳妥的做法是：
- 在 logrotate 配置中设一个宽松的
rotate 1000（避免过早删文件） - 单独写一个
cleanup-yearly.sh脚本，用find /var/log/app -name "app.log-????????" -mtime +1095 -delete按文件名解析日期（需配合dateformat格式）或用stat -c "%y %n" | awk提取实际归档时间 - 通过 cron 每月执行一次该脚本，比依赖 logrotate 自身清理更可控
冷备归档：把超期日志移出本地，腾空间又保历史
真正要存 5–10 年日志，不应全留在 /var/log。推荐分层策略：
- logrotate 本地保留最近 1 年（
maxage 365+dateext） - 每月用脚本将前 12–24 个月的归档打包为
app-2023-Q3.tar.gz，打上 SHA256 校验码 - 同步至 NFS、对象存储（如 MinIO/S3）或离线磁带；本地只留软链接或清单文件
- 归档包内保留原始压缩日志 + 解压说明 +
logrotate.conf快照，便于未来回溯
避免常见坑：命名、权限与时间精度
超长周期维护失败，常因细节失控：
-
不要用
daily+rotate 3650：万一某天没触发轮转，会堆积大量未压缩日志，撑爆磁盘 - 确保
dateformat与find脚本匹配，例如用了dateformat -%Y%m%d-%H%M，清理脚本就必须按该格式解析 - logrotate 运行用户（通常是 root）需对归档目录有读写权；若归档到 NFS，确认挂载选项含
noac避免属性缓存异常 - 跨年轮转时，
postrotate可加test -f /var/log/app/app.log-$(date -d 'last year' +\%Y)1231 && echo "archived"做轻量校验
