一台韩国服务器的业务目录尚能读取，应用却开始写入失败，备份任务也连续报错。排查时发现，业务文件所在分区并未满，真正耗尽的是 /var 所在文件系统：日志仍在增长，备份任务的临时文件也落在这里。这样的场景提醒运维人员，预防磁盘爆满不能只盯整台服务器的“剩余空间”。

有效的检查应同时覆盖各写入文件系统的空间与 inode、增长速度、日志轮转状态，以及备份目标和临时目录的容量。下面以常见 Linux 环境为例；执行前应确认实际挂载点、日志管理方式和备份路径。验收时不仅要看到空间恢复，还要确认写入正常、下一轮日志和备份任务不会再次把空间耗尽。

先确认写入究竟落在哪个文件系统

收到磁盘使用率告警后，先不要删除文件。应用写入失败可能由数据块耗尽、inode 耗尽、目标挂载丢失，或文件系统变为只读引起；它们的处理方法不同。

在具备相应查看权限的 Linux 主机上，可先执行只读检查：

date -Is
df -hT / /var /var/log
df -i / /var /var/log
findmnt -T /var/log -o TARGET,SOURCE,FSTYPE,OPTIONS

df -hT 查看容量和文件系统类型，df -i 查看 inode。/、/var、/var/log 若显示同一个文件系统，不应把它们的剩余空间相加；若分别挂载，就要分别监控。findmnt 用于确认路径实际落在哪个设备及其挂载选项。服务器没有安装该工具时，先核对挂载信息，再决定是否安装，不必为一次检查贸然改变生产环境。

接着核对应用上传目录、数据库数据目录、日志目录和备份临时目录。不要根据目录名推断磁盘位置：例如备份目录原本应是独立挂载点，但挂载失败后，程序仍可能把文件写进根文件系统。对预期的独立挂载点，应检查它是否确实挂载了预期来源，而不只是检查目录是否存在。

这一步的正常状态不是“根分区还有空间”，而是每个实际写入目标都有可用余量，挂载来源符合预期，业务能够持续写入。

从占用量追到增长来源

确认了高风险文件系统后，再按目录缩小范围。以下命令以 /var 为例，需先确认它是待调查的路径；扫描繁忙目录可能产生额外 I/O，宜避开业务高峰：

sudo du -xhd1 /var
sudo du -xhd1 /var/log

-x 将统计限制在当前文件系统内，有助于避免把其他挂载卷混入结果。若日志目录突出，应继续区分系统日志、应用日志、轮转后的归档文件；若备份暂存目录突出，应查任务是否中断后遗留文件。仅凭文件名包含“old”或“backup”，不能判定它可以删除。

还要比较两次以上的检查结果。当前使用率只能说明“占了多少”，增长记录才能回答“何时可能耗尽”。估算时，应以可用空间与近期净增长量为基础，并考虑定时备份、批量上传、日志高峰等写入波动。增长不稳定时，不要把一次低增长结果当作安全保证。

如果 df 显示空间紧张，而 du 找不到相近的目录占用，可检查是否有进程仍占用已删除文件。主机安装了 lsof 时，可使用：

sudo lsof +L1

存在结果说明文件名虽已删除，空间仍可能被打开它的进程占用；但差额也可能涉及文件系统预留空间、快照或其他存储机制，不能仅凭这一条命令下结论。不要为释放空间直接重启关键进程，应先确认进程、业务影响和可用的维护窗口。

让监控覆盖“会写满”的位置

监控应按文件系统和写入用途配置，而非只配置一个全局磁盘百分比。至少要纳入空间使用、inode 使用、可用容量的变化趋势、关键挂载点状态，以及磁盘告警是否送达值班人员。应用日志、数据库、上传目录、备份暂存目录若位于不同文件系统，应分别呈现。

告警线应结合业务增长和处置时间设定：从发出告警到人员确认、清理或扩容完成，期间仍会有新数据写入。因而验收时要问的是“剩余空间能否覆盖这段时间和下一次集中写入”，而不是机械套用同一个百分比。备份任务若会短时产生较大的临时文件，还应核对峰值阶段的空间，而不只看任务结束后的占用。

一次监控验收可这样进行：

1. 对照 df 与监控页面，确认文件系统名称、挂载点、空间及 inode 数据对应正确。
2. 核对应用目录和备份暂存目录是否被纳入；独立挂载点缺失时，应有异常提示，而不是静默显示上一级分区“正常”。
3. 通过监控系统提供的测试通知或规则测试功能，确认告警能到达实际值班渠道；不应靠人为写满生产磁盘测试。
4. 保留测试时间、规则条件、通知记录和当时的容量截图或命令输出，便于事后判断是未触发、未发送，还是无人接收。

日志清理要先核对轮转，再处理存量

在典型现场中，日志占满磁盘往往不是“忘记删一次文件”这么简单。更值得检查的是轮转任务是否执行、应用是否不断生成异常日志、保留期是否符合要求，以及压缩归档是否仍落在同一块紧张的磁盘上。

使用 logrotate 的系统，可在确认工具和配置文件存在后，先做调试检查：

command -v logrotate
sudo logrotate -d /etc/logrotate.conf

-d 用于查看轮转判断，不实际修改日志。仍须核对系统是否通过定时器或其他计划任务运行轮转，以及相关应用日志是否被配置覆盖。不要看到规则文件存在，就认定轮转一直成功。

使用 systemd journal 的系统，可先查看其占用：

sudo journalctl --disk-usage

若确认历史 journal 超出已批准的保留要求，并已将需要留存的记录备份到另一处且验证可读取，才考虑轮转和清理。例如保留要求明确允许删除超过 14 天的归档时，可执行：

sudo journalctl --rotate
sudo journalctl --vacuum-time=14d
sudo journalctl --disk-usage

这里的 14 天只是满足该保留要求时的命令示例，不应直接作为所有业务的保留期。清理会删除符合条件的归档 journal；vacuum 主要作用于归档文件，不能保证把占用降到某个指定值。操作前应记录原占用、批准的保留范围和异地备份位置。误清理后只能从事先保存的副本恢复所需记录，不能假定已删除的历史日志可以在原机自动找回。

普通应用日志也不宜对正在写入的文件直接 rm、覆盖或清空。这可能造成记录缺失，且被进程占用的已删除文件未必立即释放空间。应优先修正轮转与应用重新打开日志文件的机制；如确需清理旧归档，先核对文件范围、留存要求和独立备份，再分批操作。每批之后用 df、目录统计和应用写入状态验证效果；异常时停止后续清理，并从备份中恢复所需归档。若涉及服务重启，另须评估中断影响并准备服务回退方案。

备份成功与“备份放得下”要分别验收

备份任务显示成功，不代表下一次仍有足够空间；备份存储尚有容量，也不代表本机暂存目录不会先写满。检查时应沿实际数据路径逐段核对：源数据所在文件系统、备份过程的本地临时目录、最终备份目标，以及备份平台显示的配额或容量。

对本地独立备份卷，先确认预期挂载点和来源，再查看其容量。若备份写入远端或对象存储，本机 df 不能代替目标端的容量、配额和任务状态检查。容量评估应包含下一次任务可能新增的数据、保留期内既有备份，以及清理或合并旧备份时可能需要的空间。采用增量备份时，尤其不能把旧备份链中的某个文件随意删除来腾位置。

备份验收至少包括三件事：任务记录显示按计划完成；目标端能找到对应备份且容量趋势可解释；按既定流程做过恢复验证。恢复测试应优先在隔离位置进行，记录恢复点、抽查内容和结果，避免用生产目录作覆盖测试。若容量不足，应先核对保留策略和可恢复链条，再选择增加容量或按策略淘汰备份。任何删除前都要确认独立副本及恢复需求；误删时的回退依赖事先存在的副本，而非任务状态页面上的“成功”字样。

最后一轮验收：证明风险已解除

处置完成后，工程人员不能只留下“已清理若干空间”的记录。建议把以下项目作为交接核对：

• 容量与 inode：各实际写入文件系统低于本机告警条件，剩余量足以覆盖预计增长和下一次集中写入；记录处置前后同口径的 df 输出。
• 挂载与写入：关键挂载来源符合预期，应用和备份暂存路径没有误落到根分区；通过正常业务写入或任务记录确认写入恢复。
• 日志：轮转规则及执行方式已核对，清理后日志仍持续产生，新归档符合保留要求；保存调试结果、执行时间和清理范围。
• 备份：源端、暂存位置、目标端均有余量，最近一次任务状态可核对，恢复测试有记录。
• 告警：空间、inode、趋势和挂载异常的规则已覆盖相应目标，测试通知到达实际接收人。

留证时记录检查时间、主机及挂载点标识、命令或监控结果、任务编号与处理人；分享日志或截图前应遮盖凭据及敏感业务数据。若清理后很快再次逼近告警线，或日志仍异常高速增长，就不能把这次验收判为通过，应继续查明持续写入的来源。

最容易漏掉的是两处：备份挂载丢失后，文件悄悄写入根分区；日志已清理，但下一轮轮转或备份仍会失败。把挂载、增长趋势和下一次任务结果纳入复查，才能将一次空间处置变成可持续的预防措施。