凌晨三点，监控大屏突然飙红，SSH 连上去敲个 ls 都卡半天，紧接着业务进程开始报 “No space left on device”。作为站长，这绝对是比被 DDoS 还让人心跳加速的场景。磁盘爆满不是最可怕的，可怕的是你一通 rm -rf 猛如虎，回头发现服务起不来，数据也找不回了。
今天笔者不跟你扯虚的，直接把这套在死亡边缘试探出来的“磁盘爆满紧急排查与安全清理 SOP” 交出来。这套流程的核心逻辑是：先定位、再判断、后清理、终验证。只要按着这个节奏走，哪怕你是刚接手的新手，也能在十分钟内让服务器转危为安。
一、核心原理概述：为什么删了文件，空间却没回来？
💡 推荐阅读：CPU 飙到 100% 别急着重启！一文讲透云服务器高负载的排查与根治
在动手之前，我们必须先搞懂 Linux 文件系统的“潜规则”。很多新手都会遇到一个灵异事件：明明用 rm 删除了几个 G 的日志，df -h 一看，磁盘还是 100%。
这背后的元凶通常有两个：
- 僵尸文件句柄（Deleted but Open）： 进程还在往这个文件里写数据，虽然文件目录项被删了，但只要进程不重启，内核就认为文件还在被使用，磁盘块就不会释放。
- 硬链接（Hard Link）： 你以为删了源头，其实别处还有个“分身”指着同一块数据。
所以，我们的排查思路不能只盯着 du 看到的目录大小，必须结合 lsof 去看进程层面的占用。
二、生产环境架构规范：分秒必争的排查四步法
💡 延伸阅读：云服务器选型横评：个人博客与小型团队项目到底需要什么配置？
当收到磁盘告警，请立刻按以下顺序操作，不要跳步。
1. 确认战场：到底是哪个分区满了？
别上来就瞎找，先锁定目标。笔者习惯用 df -hT，加上 -T 能看清文件系统类型，避免误判。
df -hT
# 输出示例：
# Filesystem Type Size Used Avail Use% Mounted on
# /dev/vda1 ext4 40G 40G 0 100% /
# /dev/vdb1 xfs 200G 45G 155G 23% /data
看到 Mounted on 是 / 且 Use% 为 100%，那问题就出在系统盘。如果是 /data 满了，就去查数据盘。
2. 逐层深入：揪出占用大户
锁定了分区，比如是 /，那就从根目录开始剥洋葱。这里有个小技巧，用 --max-depth=1 只看一层，避免屏幕刷爆。
du -h --max-depth=1 / | sort -rh | head -20
这条命令的意思是：统计根目录下每个一级子目录的大小，按人类可读格式显示，并从大到小排序，只看前 20 个。通常凶手就在 /var、/usr 或 /home 里。
假设发现 /var 占了 30G，那就继续往下钻：
du -h --max-depth=1 /var | sort -rh | head -20
层层递进，直到定位到具体的 .log 或 .tar.gz 文件。
3. 终极杀招：检查“隐身”的僵尸文件
如果 du 统计出来的总大小和 df 显示的已用空间严重不符（比如 du 只有 5G，df 却说 40G 满了），别犹豫，直接上 lsof。
lsof | grep deleted | grep -E 'log|data' | awk '{print $1, $2, $7, $9}' | sort -k3 -nr | head -20
这行命令会列出所有被删除但仍在被进程占用的文件。重点关注 COMMAND（进程名）、PID（进程号）和 SIZE。如果看到某个 Java 进程或 Nginx 进程占着几十个 G 的 deleted 文件，那就是它了。处理方式： 优雅重启该进程（systemctl restart nginx），空间瞬间释放。
三、性能/安全加固调优清单：清理不是删库跑路
💡 深度技术指南：别再花冤枉钱！云服务器2核2G和2核4G真实跑分对比，看完再买不踩坑
找到大文件后，千万不要直接 rm -rf。生产环境讲究的是“软着陆”。
| 文件类型 | 常见路径 | 安全清理策略 | 风险等级 |
|---|---|---|---|
| 应用日志 | /var/log/nginx/*.log | echo > filename 或 logrotate 切割 | 低 |
| 系统日志 | /var/log/journal/ | journalctl –vacuum-size=200M | 低 |
| 包管理器缓存 | /var/cache/yum 或 apt | yum clean all 或 apt clean | 低 |
| 旧内核 | /boot | 包管理器卸载旧内核（谨慎） | 中 |
| 用户数据 | /home/*/ | 确认无用后打包迁移至对象存储 | 高 |
特别提醒： 清理日志文件时，绝对禁止 直接 rm。因为 Nginx、Tomcat 这类进程是通过文件描述符写日志的，你 rm 掉后，进程不会自动创建新文件，日志就丢了。正确的姿势是：
# 清空而非删除
echo "" > /var/log/nginx/access.log
# 或者用 logrotate 切割
logrotate -f /etc/logrotate.d/nginx
四、验证测试与 SOP 总结
清理完成后，必须做两件事来验证：
- 再次执行
df -hT，确认Use%已经降下来，且业务进程没有报错。 - 观察 5 分钟，看磁盘使用率是否在缓慢回升。如果回升极快，说明有进程在疯狂写日志，这时候就要去查代码或配置了，而不是单纯删文件。
最后，笔者把压箱底的 SOP 口诀 送给你：
一查 df 定分区，二用 du 剥洋葱，三看 lsof 抓僵尸，四清日志用 echo，五验业务保平安。
当然，与其每次火急火燎地救火，不如一开始就选个靠谱的云服务器。像笔者自己用的几台机器，都是挑的大厂云服务，系统盘清清爽爽，数据盘单独挂载，再配合定时任务自动切割日志，压根不给磁盘爆满的机会。如果你正准备入手新机器，记得选那种支持弹性扩容的，万一真满了，后台点一下扩容比 SSH 敲命令可快多了。
希望这篇 SOP 能帮你安稳睡个好觉。下次再看到 100%，别慌，按这个流程走，稳得很。