磁盘空间被写满，往往不是一瞬间发生的。多数时候是日志、缓存、临时文件、备份包一类的东西慢慢堆积，直到某个时刻应用写不进日志、数据库无法写入、上传失败，网站开始报错。蜘蛛来抓取时遇到 5xx 或连接中断，抓取记录也会变得难看。定期做一次日志与磁盘空间自查，比等故障发生再处理要轻松得多。

日志为什么会悄悄吃掉磁盘

访问日志、错误日志、应用调试日志、数据库慢查询日志，各自增长速度不同。访问量大的站点，单个访问日志每天增长几百 MB 并不少见。如果只按天切割却不删除、不压缩，几个月后就能占满小磁盘。

还有几种容易被忽略的情况：

• 调试日志忘了关，框架把每个请求的详细上下文都写进文件。
• 错误日志被反复刷新，某个循环报错在短时间内产生大量重复记录。
• 日志切割后旧文件没有压缩，保留数量设得过大。
• 临时目录被上传、导出、缓存文件占用，和日志一起挤压剩余空间。

先看几个信号

• 网站偶发 500，刷新后恢复，过一会儿又出现。
• 数据库提示“磁盘已满”或进入只读模式。
• SSH 登录后提示无法写入，命令补全失效。
• 日志文件最后修改时间停在某个时间点，之后没有新内容。
• 监控里磁盘使用率持续上升，没有回落。

出现这些信号时，先确认磁盘和 inode 的使用情况，再决定是清理还是扩容。

检查磁盘与 inode

登录服务器后，用几个基础命令快速定位：

• df -h：查看各分区剩余空间，关注 / 和 /var 这类常用分区。
• df -i：查看 inode 使用率。即使空间还有，inode 耗尽也会导致无法创建新文件。
• du -sh /var/log/*：查看日志目录下各文件或子目录大小。
• du -sh /tmp /var/tmp：检查临时目录占用。
• find / -xdev -size +500M -type f：找出大文件，可按需调整路径和大小阈值。

如果 du 统计的总和与 df 显示的已用空间差距很大，可能有文件已被删除但进程仍持有句柄，或者存在挂载点被覆盖的情况。可以用 lsof 查看被删除但仍占用的文件。

日志轮转的基本做法

Linux 上常见的是 logrotate。它按时间或大小切割日志，并可选择压缩和保留份数。大多数发行版已经为系统日志配好了规则，但自己部署的应用、Nginx、PHP、数据库等需要单独确认。

配置时重点看这几项

• rotate：保留多少个历史文件。访问日志保留 7 到 30 天较常见，按分析需求决定。
• daily / weekly / size：触发切割的条件。写量大的日志可以用 size 辅助。
• compress 与 delaycompress：是否压缩旧日志。压缩能省不少空间。
• copytruncate 或 create：前者适合不支持重开日志文件的应用，但极端情况下可能丢少量日志；后者需要应用配合重载。
• postrotate：切割后通知服务重新打开日志文件，避免继续写旧句柄。

应用自己管日志时

有些应用框架内置日志滚动，比如按天写文件、按大小切割。要确认它是否同时限制文件数量和总大小。只按天切割但不清理，长期看仍然会涨。可以设置保留天数，或把日志输出到标准输出交给容器和日志采集系统处理。

保留周期与归档

不是所有日志都必须长期留在服务器上。可按用途分层：

• 最近 7 天的原始日志留在本地，便于排查最近问题。
• 更早的日志压缩后归档到对象存储或另一块磁盘。
• 需要长期分析的访问日志，先确认合规和隐私要求，再决定保留范围。
• 调试日志、临时导出文件设定明确的生命周期，用完就清。

归档之后，服务器上只保留必要窗口，磁盘压力会小很多。

清理时的注意事项

• 不要直接删除正在写入的日志文件。进程可能仍持有句柄，空间不会立即释放。可以用 truncate 清空，或先停服务、切割、再删除。
• 删除前确认文件用途，避免误删数据库文件、证书、备份或业务上传目录。
• 如果访问日志还要用于分析蜘蛛抓取和流量来源，不要因为清理磁盘全部删掉。
• 清理后再次运行 df -h，确认空间确实释放。

把磁盘监控加进日常

• 设置磁盘使用率告警，比如超过 80% 提醒，超过 90% 升级处理。
• 同时监控 inode 使用率，避免只看空间不看文件数。
• 对日志增长速度做趋势记录，提前判断扩容时间。
• 把日志轮转配置纳入服务器初始化清单，新机器上线时就配好。

磁盘空间和日志轮转是容易被忽略的基础项。它们平时不出声，一旦出问题却可能让整站短时间不可用。把它放进每月自查，比事后救火省事。

建议在业务低峰期做一次完整检查：看当前占用、确认轮转规则、清理无用文件、设置告警。做完后记录一份现状，下次对照变化即可。