Linux find 删除旧日志怎么避免误删：mtime、路径边界与 dry-run 验证

清理 Linux 服务器旧日志时，最稳妥的做法不是把 find 命令写得更短，而是先固定目录，再用文件类型和修改时间收窄范围，最后把“列出候选”和“真正删除”拆成两个动作。这样即使日志文件名带空格、目录里有挂载点，也能在删除前留下一份可检查的候选清单。

先定义“旧日志”，再决定时间条件

假设应用日志统一放在 /var/log/myapp/，目标是清理修改时间超过七天的普通文件。这里的“超过七天”应先转换成可验证的条件：文件的修改时间已经跨过七个完整的 24 小时区间，而不是简单理解成“日期显示在七天前”。

find 的 -mtime n 按完整 24 小时区间计算。常见写法可以这样理解：

• -mtime +7：完整区间数大于 7，通常比“至少七天”更严格。
• -mtime 7：落在第 7 个完整区间内。
• -mtime -7：完整区间数小于 7，表示最近一段时间内修改过。

如果业务要求精确到某个日期、时区或文件名里的业务日期，优先用明确的时间边界和额外核对，不要只凭 ls 的人类可读时间下结论。

第一步只做预览，不触碰删除动作

先把目录和条件写死，列出候选文件：

/usr/bin/find /var/log/myapp -xdev -type f -name '*.log' -mtime +7 -print

-xdev 可以避免继续进入其他文件系统；-type f 排除了目录和符号链接；-name '*.log' 则把清理范围限制在明确的后缀。命令本身不会删除任何东西，适合先保存输出并抽样检查。

重点看三件事：候选路径是否全部位于目标目录、文件数量是否符合当天的日志增长量、最近刚生成的压缩包或归档是否被意外匹配。数量突然从几十个变成几万个时，先停下来查表达式，不要继续执行。

文件名可能有空格时，改用 NUL 分隔预览

日志目录里如果允许空格、换行或中文文件名，普通换行输出不适合直接交给后续脚本。预览时可以使用 -print0，再由只认识 NUL 分隔的工具读取：

/usr/bin/find /var/log/myapp -xdev -type f -name '*.log' -mtime +7 -print0 \
  | /usr/bin/xargs -0 -r -n 1 /usr/bin/stat --printf='%y %n\n'

这一步只读取文件状态。若只是人工查看，直接使用 -print 更容易读；若输出要进入后续程序，优先保持 -print0 和 xargs -0 成对出现，别把带空格的路径重新按空格切开。

确认清单后再执行删除，并保留失败信息

GNU find 支持用 -delete 删除匹配项，但它应该放在已经验证过的表达式末尾。正式执行前，建议先把预览保存到受控位置，并抽查前后几行：

log_root=/var/log/myapp
/usr/bin/find "$log_root" -xdev -type f -name '*.log' -mtime +7 -print \
  | /usr/bin/tee /var/tmp/myapp-log-candidates.txt

确认清单无误后，才执行同一组筛选条件的删除版本：

/usr/bin/find /var/log/myapp -xdev -type f -name '*.log' -mtime +7 -delete

删除前后都可以用 find ... -type f -name '*.log' -mtime +7 -print | wc -l 记录数量，但不要把数量变成唯一验收标准。还要检查应用是否继续写入新文件、磁盘使用率是否下降，以及最近一条日志是否仍能正常追加。

定时任务里最容易漏掉的四个边界

不要从未校验的变量拼接根目录

交互式脚本可以把目录写成只读常量，或者在执行前检查它是否等于预期路径。一个空变量、错拼的挂载点或多余的通配符，都可能让删除范围偏离设计。

不要把归档目录和在线日志混在一起

如果 /var/log/myapp/archive 由另一个任务负责，在线日志的清理表达式应明确排除它，或者给两个目录配置各自的保留周期。先靠文件名后缀再靠目录层级，通常比只写一个宽泛的 -mtime 更容易复查。

别把符号链接当成普通文件

-type f 默认只匹配普通文件。清理前仍应检查是否有链接指向其他位置；不要为了“覆盖更多文件”随意改成跟随链接的选项。

把定时任务的环境当成另一台机器

cron 的 PATH、工作目录和用户权限可能与登录 Shell 不同。命令使用绝对路径，输出重定向到专用日志，并让任务失败时能被监控发现。上线前用执行任务的同一用户跑一次预览。

一个可复用的验收清单

• 根目录是否是预期的日志目录，并且没有跨文件系统遍历？
• 是否限定了 -type f、文件后缀和排除目录？
• 时间条件是否经过样本文件核对，而不是只看命令表面？
• 是否先预览、保存清单并抽样，再执行 -delete？
• 删除后应用日志、磁盘空间和定时任务日志是否都正常？

常见问题与边界

为什么 -mtime 7 没有匹配到“七天前”的文件？

因为它按完整 24 小时区间计算，日历日期相同不代表完整区间数相同。先用 stat 查看样本的修改时间，再决定使用 +7、7 还是 -7。

可以直接把 -print 换成 -delete 吗？

只有在筛选条件、目录边界和样本清单都确认后才可以。更稳妥的流程是把预览命令保存下来，人工核对后再将同一表达式切换为删除动作。

删除日志前需要停服务吗？

不一定。是否能在线删除取决于日志框架、文件句柄和轮转策略；删除后仍被进程打开的文件可能继续占用空间。若磁盘压力已经很高，先确认进程打开文件和轮转机制，再安排低风险处理窗口。

Linux 日志清理的核心不是记住一条“万能命令”，而是让每个条件都能被解释、被预览、被复查。固定路径、限制文件类型、确认时间语义，再执行删除，通常比事后恢复误删文件可靠得多。