引言
在Linux服务器运维过程中，"磁盘空间不足"是导致服务中断的最常见原因之一。当根分区或数据分区容量达到100%时，可能导致数据库无法写入、Web服务返回500错误、甚至SSH登录失败。对于中小企业IT人员和初级运维工程师而言，快速定位占用空间的文件并安全清理是必备技能。本文将详细阐述磁盘满的排查思路与解决方案。
第一步：快速诊断与现状确认
在开始清理之前，必须明确当前磁盘的使用情况。通常使用df -h命令查看各挂载点的空间利用率：
执行命令：
df -h
重点关注Use%为100%或接近100%的Filesystem列。注意，有时候Inodes（索引节点）耗尽也会导致无法创建新文件，即使磁盘空间还有剩余。此时可使用df -i检查inode使用情况。
第二步：定位大文件与目录
一旦确定是哪个分区满了，下一步是找出是谁“吃”掉了空间。切勿盲目删除/root或/etc下的文件，应遵循由大到小、由外到内的排查原则。
2.1 从根目录向下扫描
使用du命令配合sort可以直观地看到各个子目录的大小分布：
- 命令示例：
du -sh /* | sort -rh | head -n 10 - 参数说明：
-s：汇总显示单个目录大小-h：人类可读格式（KB, MB, GB）sort -rh：按大小降序排列
通过上述命令，可以快速锁定占用空间最大的顶级目录（如/var, /home, /opt等）。
2.2 深入可疑目录
假设发现/var目录占用极大，继续在该目录下执行相同操作：cd /var && du -sh * | sort -rh | head -n 5。层层递进，直到定位到具体的文件或文件夹。
第三步：常见高占用场景及清理方案
根据经验，Linux服务器磁盘爆满主要集中在以下三个场景。
3.1 日志文件爆炸（/var/log）
应用程序崩溃、DEBUG级别日志未关闭或日志轮转失效，都可能导致syslog或特定应用日志迅速增长至GB甚至TB级别。
- 排查：在/var/log下查找大于100MB的文件：
find /var/log -type f -size +100M - 清理：
- 静态日志：如果确认日志不再需要，可直接删除：
rm -f /var/log/old_file.log - 正在被进程占用的日志：直接删除可能导致文件句柄未释放，空间无法回收。正确做法是使用
echo "" > filename清空内容，或者重启对应服务。
- 静态日志：如果确认日志不再需要，可直接删除：
3.2 临时文件堆积（/tmp 和 /var/tmp）
许多应用在运行时会生成临时文件，若程序异常退出或未正常清理，这些文件会长期滞留。
- 风险警示：不要随意删除/tmp下的所有文件，因为某些服务（如数据库、X11）可能在运行中使用了这些文件。
- 安全操作：仅删除几天前的临时文件：
find /tmp -type f -mtime +7 -delete。这表示删除超过7天的文件，确保不影响当前运行的服务。
3.3 Docker镜像与容器残留
对于使用容器的环境，Docker往往是磁盘杀手。未使用的镜像、悬空的卷和停止的容器会占用大量空间。
- 清理：执行
docker system prune -a --volumes。警告：此命令会删除所有未使用的镜像、网络和容器，请确保没有正在运行的关键容器被误删，建议先备份必要数据。
第四步：预防机制与自动化维护
清理只是治标，建立预防机制才能治本。建议实施以下策略：
4.1 配置Logrotate
Logrotate是Linux标准的日志管理工具。检查/etc/logrotate.d/下的配置文件，确保关键应用的日志设置了合理的轮转周期（如weekly）和保留数量（如rotate 4）。例如，Nginx的默认配置通常能良好工作，但自定义应用需手动添加配置。
4.2 设置磁盘监控告警
不要等到磁盘100%才行动。部署Zabbix、Prometheus或简单的Shell脚本，当磁盘使用率超过80%或90%时，通过邮件或短信发送告警。
4.3 定期清理脚本
编写crontab定时任务，定期清理过期的备份文件和临时文件。例如，每周日凌晨2点清理/var/log下超过30天的.gz压缩日志：
# 添加到 crontab -e
0 2 * * 0 find /var/log -name "*.gz" -mtime +30 -delete总结
面对Linux磁盘空间满的问题，核心逻辑是“先定位，后清理，再预防”。通过du和find命令精准找到占用源，谨慎处理正在被进程锁定的文件，并通过logrotate和监控告警建立长效机制。对于中小企业IT人员而言，掌握这套标准化的排查与清理流程，能有效减少因磁盘问题导致的业务停机时间，提升系统稳定性。