ECS 磁盘告警后别先扩容：先用 df、du 和日志定位到真正占空间的地方

前一阵子凌晨收到一条磁盘使用率超过 90% 的告警，第一反应是扩容。但后来发现，真正占地方的是一份被遗忘的旧备份，删掉之后使用率直接回到 40% 多。这件事之后，我处理磁盘告警的顺序就固定下来了：先定位，再清理，最后才考虑扩容。

第一步：先看整体，再看是哪类资源满了

先用 df 看各挂载点：

df -h
df -i

第一条看空间，第二条看 inode。很多人只看第一条，结果空间明明还剩不少，服务却写不进文件，就是小文件太多把 inode 占满了。两种满法处理方式完全不同，先分清能少走很多弯路。

确认是哪个分区满了之后，再看这个分区上跑的是什么：是系统盘还是数据盘，是数据库目录、应用日志目录，还是用户上传目录。定位到目录级别，后面的排查才有方向。

第二步：用 du 逐层往下找

直接在根目录下全量扫描又慢又吵，建议从可疑的挂载点开始，一层一层往下：

du -sh /var/* | sort -rh | head -20
du -h --max-depth=1 /data | sort -rh | head -20

找到最大的子目录后，再对它重复同样的做法，一般三四层就能锁定到具体文件或目录。这个过程不需要一次扫全盘，重点是每次只展开当前最大的那一层。

第三步：几类最常见的占空间元凶

第一类是日志。应用日志、访问日志如果没有做轮转，会一直追加。有条件的话先看 logrotate 的配置，确认是否真的在轮转，轮转周期和保留份数是否合理。临时处理可以先压缩旧日志，确认无用后再删，不要直接把正在写的文件删掉。

第二类是被删除但还没释放的文件。文件删了，空间却没回来，通常是有进程还拿着句柄：

lsof | grep deleted

这种情况删文件没用，需要重启对应服务，或者在确认安全的前提下清空文件内容，让进程继续写同一个句柄。生产环境做这一步之前，一定要先确认这个服务能不能重启。

第三类是旧备份和临时文件。备份目录里经常躺着几个月前的全量包，下载目录、解压目录里也容易堆东西。这类文件删起来最安全，但也要先确认有没有保留策略：只保留最近几份，其余的归档到对象存储，而不是直接清空整个目录。

第四类是缓存和包管理残留。构建产物、旧的容器镜像、软件包缓存，时间长了都会越积越多。清理之前先确认哪些是构建机可以重新生成的，哪些是线上正在用的，别把正在运行的镜像和依赖一起清掉。

清理之前，先做好两件事

一是确认文件归属。删之前用 ls 看一眼时间、属主和路径，含糊不清的目录先不动，先问清楚这是谁的。二是重要数据先做快照或备份。云服务器上做快照的成本，远低于误删业务数据之后的恢复成本。清理动作本身也要记下来：删了什么、为什么删、保留了几份，下次再遇到同样告警，就不用从头猜。

什么时候才轮到扩容

清理完如果使用率仍然长期在 80% 以上，而且增长来自真实的业务数据，比如订单图片、用户上传文件在持续增加，这时候扩容才是合理的。扩容之前顺便把告警阈值也调一下：80% 提醒、90% 告警，留出处理时间，而不是等到 95% 才被叫醒。

另外，扩容不是一劳永逸。扩完之后如果没有把日志轮转、备份保留策略补上，几个月后还是会收到同一条告警，只是数字变大了。

一个可复用的检查清单

1. df -h 和 df -i，确认是空间满还是 inode 满。
2. du 从大到小逐层定位，先锁定目录，再锁定文件。
3. 排查日志轮转、已删除未释放文件、旧备份和缓存。
4. 删之前确认归属，重要数据先快照。
5. 清理后观察一天，确认使用率稳定，再决定是否扩容。

磁盘告警并不可怕，可怕的是不看原因就扩容，或者不确认就乱删。按上面这个顺序走一遍，大多数告警在半小时内就能定位清楚。