磁盘满了先别急着删：用 df、du、find 三步定位真凶

云服务器最常见的半夜报警不是 CPU 跑满，而是磁盘满了：网站写不进日志、数据库拒绝写入、更新包下载到一半失败。很多人第一反应是进几个大目录挨个删，删错了系统文件反而把机器搞挂。正确顺序是先看全局、再定位目录、最后确认文件能不能删，三步走完再动手。

第一步：看全局，区分是空间满还是 inode 满

先跑 df -h，看哪个挂载点用了 100%。根分区满和数据盘满，处理方向完全不同，别在根分区满的时候去清数据盘。顺手再跑 df -i 看 inode 使用率：小文件特别多时，空间还剩不少、inode 却先用完了，表现同样是“写不进去”，这时删大文件没用，得清掉成千上万的小文件，比如过期的会话文件和缓存碎片。

第二步：逐层下钻，找到真正的大户

从根目录开始逐层查，别一上来就 du -sh /* 之外再无下文：

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

锁定最大的目录后再往里钻一层，例如 /var 偏大就查 du -sh /var/*。日志、备份、数据库数据目录是最常见的三类大户。怀疑某个目录时，用 find 直接列出大文件，比一层层 du 更快：

find /var -type f -size +100M -exec ls -lh {} \; 2>/dev/null

如果要找最近暴涨的文件，加上 -mtime -1，只看一天内改动过的，配合日志暴涨的排查特别有效。

第三步：动手前先确认能不能删

定位到文件后别急着 rm，先分三类处理。第一类是日志：正在被进程写着的日志不能直接 rm，删了文件、进程还握着句柄，空间并不会释放，正确做法是截断：: > /var/log/xxx.log，或者用 journalctl --vacuum-size=500M 给 systemd 日志瘦身。第二类是包管理缓存：apt clean、旧内核和无用的容器镜像属于可安全清理的范畴，但删之前确认没有正在进行的安装任务。第三类是业务数据和备份：数据库文件、用户上传、唯一一份的备份，哪怕再大也不能凭感觉删，先挪到对象存储或另一块盘，确认新位置能读再删旧的。

还有两个容易漏的点。一是“已删除但未释放”：文件 rm 了、空间没回来，用 lsof | grep deleted 查是哪个进程还占着，重启对应服务才能真正释放。二是根因：日志一天涨几个 G，光清一次管不了几天，要顺手看看是哪个服务在刷错误日志，把报错修掉，或者给日志加上轮转和保留天数，否则下周同一时间会再报警一次。

磁盘清理的原则就一条：先定位、再分类、最后动手，删的每一步都能说出理由。养成每月看一次 df -h 和最大目录的习惯，比半夜被报警叫醒划算得多。