服务器磁盘满了怎么排查:四步定位,删前先确认归属

先用 df 分清是空间满还是 inode 满,再用 du 逐层找大目录,接着查已删除但仍被进程占用的文件,清理前确认归属,优先轮转、压缩、迁移。

要点速览

• 先用 df -h 与 df -i 分清空间满还是 inode 满
• 用 du 从挂载点逐层缩小,常见来源是日志、临时文件、容器、备份
• du 与 df 对不上时,用 lsof 查已删除仍被占用的文件
• 删前确认归属与用途,优先轮转、压缩、迁移并留记录
• MaxTerm 可解释输出、提示方向,高风险命令由人确认执行

服务器磁盘满了,建议按四步排查:先用 df -h 和 df -i 分清是空间满还是 inode 满;再用 du 逐层缩小到具体目录;然后检查有没有「已删除但仍被进程占用」的文件;清理前确认文件归属和用途,优先轮转、压缩、迁移,而不是直接 rm。多数磁盘告警都能在这四步里找到原因。真正容易出问题的是第四步,磁盘空出来了,业务也可能跟着出问题。下面按顺序讲每一步看什么、怎么判断,以及哪些动作需要人工确认后再执行。

第一步:先确认现象,分清空间满还是 inode 满

业务侧的表现通常是写文件失败、日志报「No space left on device」、数据库无法写入,或者监控发来磁盘使用率告警。看到这类报错,先不要急着找大文件,因为「设备没有剩余空间」这个报错有两种完全不同的成因。

• df -h:查看每个分区的容量、已用、可用和挂载点。重点看报错路径实际落在哪个挂载点上,比如业务写的是 /data,满的却是根分区,说明 /data 可能根本没有单独挂载,数据写到了根分区。
• df -i:查看每个分区的 inode 使用情况。inode 可以理解为文件的「编号额度」,每个文件、目录都要占一个。如果空间还有很多,但 inode 用满了,同样写不进新文件。

两者对应的排查方向不一样:空间满,找的是「大」文件;inode 满,找的是「多」文件,通常是某个目录里堆了海量小文件,例如会话文件、缓存碎片、未清理的邮件队列或程序生成的临时文件。先把方向定对,后面能少走很多弯路。

这一步还有一个顺手要做的事:确认告警是持续增长还是突然暴涨。持续缓慢增长,多半是日志或数据自然积累;短时间内涨满,更可能是某个程序异常、循环写日志,或者有大文件被一次性写入。前者可以计划处理,后者要先找到正在写入的进程,否则清了还会再满。

第二步:用 du 逐层缩小范围,找到占用的大头

确定了是哪个分区满,下一步是从挂载点开始,一层一层往下看。常用的写法是 du -xh --max-depth=1 挂载点 | sort -h。其中 -x 表示不跨越到其他文件系统,避免把别的挂载点也算进来;--max-depth=1 只看下一层,配合 sort -h 按大小排序,一眼能看出哪个目录占得多。找到占用大的目录后,再进入该目录重复执行,直到定位到具体的文件或子目录。

如果是 inode 满,思路相同,只是统计的对象换成文件数量。较新的 du 版本支持 --inodes 参数,也可以用 find 配合计数,逐层找出文件数量异常多的目录。

实际排查中,占用大头通常落在这几类来源里:

• 日志:应用日志、Web 服务访问日志、系统日志。没有配置轮转,或者轮转了但旧文件没有压缩和过期删除,时间一长就会累积。
• 临时文件:/tmp、应用自己的缓存目录、上传中转目录。程序异常退出时,临时文件往往没有被清理。
• 容器与镜像:使用容器的服务器,镜像、停止的容器、未使用的数据卷和构建缓存会占用大量空间,可以先用容器工具自带的磁盘统计命令查看各部分占用。
• 备份:数据库导出文件、打包的历史版本、迁移时留下的副本。这一类常常是「当时有用、后来忘了」。

也可以用 find 按大小直接找大文件,例如查找某个目录下超过一定大小的文件,作为 du 的补充。两种方法结合,定位通常不需要太久。

第三步:容易漏掉的一类,已删除但仍被占用的文件

有一种情况经常让人困惑:du 统计出来的总量明显小于 df 显示的已用空间,或者明明已经删了一个大日志文件,df 看到的可用空间却没有变化。

常见原因是:文件虽然从目录里删掉了,但还有进程打开着它。在 Linux 里,只要有进程持有文件句柄,这个文件占用的空间就不会被释放。du 按目录遍历,看不到这些文件;df 按文件系统统计,仍然算着它们。典型场景是有人直接 rm 了一个正在被服务写入的日志文件。

排查思路是用 lsof 列出已删除但仍被打开的文件,例如 lsof +L1,或者在 lsof 输出里筛选标记为 deleted 的条目。输出里会显示进程名、进程号和文件大小,据此可以判断是哪个服务占着空间。

处理方式要谨慎:

• 如果是日志类文件,通常的做法是让对应服务重新打开日志文件,很多服务支持通过信号或自带命令完成,不需要重启。
• 如果只能通过重启服务来释放,就要评估业务影响,安排在合适的时间窗口,并提前通知相关人员。
• 不建议在不了解进程用途的情况下直接结束进程。空间是释放了,但可能中断了正在进行的业务。

需要说明的是,du 和 df 数字对不上不一定都是这个原因,挂载点被覆盖(某个目录先写了数据、后来又在上面挂载了新磁盘)、文件系统保留空间等也会造成差异。lsof 这一步是排查方向,不是唯一结论,看到结果后仍要结合实际情况判断。

一份对照清单:命令、看什么、哪些要人工确认

把上面的步骤整理成清单,方便值班时对照使用:

• df -h:看哪个分区满、挂载点是否符合预期。只读命令,可以直接执行。
• df -i:看 inode 是否耗尽,决定找「大」还是找「多」。只读命令,可以直接执行。
• du 逐层统计:看哪个目录占用多。只读,但在文件量很大的目录上会消耗磁盘读写,业务高峰时要留意。
• find 按大小或数量查找:定位具体文件。只读;若加上删除参数就变成高风险操作,必须人工确认。
• lsof 查已删除文件:看哪个进程占着空间。只读;后续的重载、重启、结束进程需要人工确认。
• 容器清理命令:可能删除镜像、容器和数据卷。需要确认哪些仍在使用,数据卷尤其要小心。
• rm、清空文件、截断日志:不可逆或难以回退。必须确认文件归属和用途,并做好记录。

简单说,查看类命令可以放心用,改变状态的命令都要停一下。关于终端里哪些命令需要人工把关,可以参考终端AI运维命令执行安全:哪些命令要人工确认?里按风险分档的做法。

第四步:处理与回退,删之前先确认什么

找到大头之后,真正要小心的是怎么处理。磁盘告警带来的时间压力,容易让人直接 rm 了事,但误删配置、数据或正在使用的文件,后果往往比磁盘满更麻烦。动手之前,建议先回答这几个问题:

1. 这个文件属于谁:是哪个服务、哪个项目、哪个同事产生的。不确定就先问,不要凭文件名猜。
2. 它还有没有用:是否仍在被读写,是否是某次问题排查需要保留的证据,是否有合规或审计上的保留要求。
3. 删了能不能找回:有没有其他副本,是否需要先备份到别的位置。
4. 处理方式是否只有删除:很多情况下有更稳妥的选择。

常见的更稳妥做法:

• 轮转:为日志配置按时间或大小轮转,并设置保留份数,从源头控制增长。
• 压缩:历史日志、旧备份压缩后保留,占用会明显下降,需要时仍可查阅。
• 迁移:把备份、归档数据移到专门的存储或其他分区,而不是长期放在系统盘上。
• 截断而非删除:对正在被写入的日志,清空内容比删除文件更不容易出现第三步那种空间不释放的情况,但同样要确认内容不再需要。

每一次清理都建议留下记录:清理了哪些路径、多大、依据是什么、谁确认的、执行时间。这样既方便日后复盘,也能在业务出现异常时快速判断是否与清理有关。临时处理完之后,还要把根因处理掉,比如补上日志轮转、调整备份保留策略、给数据目录单独挂载磁盘,否则同样的告警过一段时间还会出现。

如果清理之后空间仍然不够,说明业务本身的数据量已经超出了当前磁盘规划,这时就需要考虑扩容或调整存储结构了。

排查时可以借助的工具与现场支持

上面这些命令本身不复杂,难点在于读懂输出、判断下一步往哪里查。尤其是不常处理这类问题的开发人员,面对 lsof 的大段输出或 du 的层层结果,容易漏看关键信息。

润迅的 MaxTerm 是一款终端 AI 运维工具,支持 macOS 和 Windows,个人免费。在磁盘排查这类场景里,它的作用是解释命令输出、提示下一步可以查看的方向,比如说明 df 和 du 数字为何对不上、某个进程占用的已删除文件意味着什么。删除、清理、重启服务这类有风险的操作,仍由运维人员确认后执行,AI 只做解释和提示,不替人做决定。

磁盘问题有时会和其他故障一起出现,例如根分区满导致服务异常,进而影响远程登录。遇到连不上服务器的情况,可以参照服务器SSH连不上怎么排查:按网络端口认证服务四段定位先恢复访问,再处理磁盘。

行动建议:把这次排查变成下一次的预案

• 把四步排查顺序和对照清单整理成团队文档,值班人员遇到告警时按步骤执行,不跳步。
• 为磁盘空间和 inode 分别设置告警,并在告警里注明分区和挂载点,减少第一步的判断时间。
• 梳理各服务的日志轮转和备份保留策略,明确每个数据目录的负责人,删前确认时有人可问。
• 清理操作留记录、留备份,高风险命令执行前由第二人复核。
• 需要在终端里辅助读懂输出的,可以试用 MaxTerm 终端 AI 运维工具,让它解释结果、提示方向,执行与否由你决定。

如果服务器托管在润迅的数据中心,清理后仍需加装或更换硬盘等现场操作,可以通过机房配套服务沟通现场安排,也可以拨打业务热线 400-854-5566 咨询。

→ 联系润迅,聊聊你的场景,获取适合的方案