Linux磁盘空间告警时，先别急着删文件：一次从定位到清理的排查笔记

磁盘满了的时候，最危险的操作往往不是磁盘本身，而是人在慌乱中删错文件。本文用一个常见的运维场景，把排查顺序讲清楚：先定位分区，再定位目录，最后才决定删什么、怎么删。

第一步：确认是哪一个分区满了

先用 df 看整体情况，同时关注两个指标：空间使用率和 inode 使用率。空间没满但 inode 满了，也会出现写不进文件的情况。

df -h
df -i

如果根分区满了，要格外谨慎；如果只是数据分区或日志分区满了，影响范围相对可控。先把分区和挂载点记下来，后面的排查都围绕它展开，不要在全盘范围内盲目搜索。

第二步：从大到小定位占用目录

进入可疑分区后，用 du 按目录汇总大小，再排序找最大的几项。加上 -x 可以避免跨到其他挂载的文件系统，减少干扰。

du -sh /* 2>/dev/null | sort -rh | head -20
du -sh /var/* 2>/dev/null | sort -rh | head -20

找到大目录后，再一层一层往下钻，直到定位到具体的文件或子目录。这一层工作做扎实，后面就不会出现“删了一堆小文件，空间却没变化”的尴尬。

第三步：区分三类最常见的元凶

第一类是日志。应用日志、系统日志和容器日志都可能在短时间内暴涨。先看 /var/log 的大小，再看 journal 的占用情况，确认是正常增长还是某个服务在反复报错。

journalctl --disk-usage
ls -lh /var/log | sort -k5 -rh | head -20

第二类是临时文件和缓存。下载目录、构建产物、包管理缓存和旧的备份文件，常常在不知不觉中占据大量空间。这类文件一般可以再生，但删除前仍要确认是否还有业务在用。

第三类最容易被忽略：文件已经被删除，但仍被进程占用。此时 df 显示空间没有释放，因为文件句柄还没有关闭。用 lsof 检查 deleted 项，就能发现这类“幽灵占用”。

lsof | grep deleted

第四步：按安全顺序清理

清理的原则是：先处理可再生的数据，再处理可重建的缓存，最后才考虑业务数据，而且每一步都要先确认归属。日志可以先归档再轮转，正在被进程写的文件不要直接删除，改用清空内容的方式处理，例如对日志文件做截断。

对于被删除仍占用的文件，正确做法是重启相关服务或让进程释放句柄，而不是反复删除其他文件。清理完成后，立刻再跑一次 df，确认空间确实释放了，并且服务日志还在正常写入。

几个容易踩的坑

不要用通配符删除系统目录下的文件，也不要在没有确认的情况下清理根分区。不要把“空间释放了”当成问题解决了：如果某个服务一直在写错误日志，空间很快又会满。真正收尾的动作，是找到写日志的原因，修掉它，或者把日志轮转和保留策略配好。

另外，删除前问自己三个问题：这个文件是谁写的？现在还有没有进程在用它？删掉之后能不能再生或从备份恢复？有一个问题答不上来，就先不要删，先移动到临时目录观察一段时间。

平时可以做的预防

给磁盘使用率设两档告警，例如八成提醒、九成处理，留出处理时间而不是等到写满才动手。给关键日志配好轮转，限制单个日志文件和总保留量；给备份和构建产物定好保留天数，到期自动清理。定期跑一次 du 汇总，心里对“正常占用”有个基线，异常增长一眼就能看出来。

磁盘告警不可怕，可怕的是没有顺序的清理。先定位分区，再定位目录，再区分日志、缓存和被占用文件，最后按安全顺序处理并验证结果，这套流程在大多数 Linux 服务器上都适用，也能帮你在深夜告警时少走很多弯路。