服务器磁盘写满，通常不是一瞬间发生的。它更像一个缓慢积累的过程：访问日志一天天追加，临时文件没有清理，旧备份留在本地，数据库日志悄悄膨胀。等到某天凌晨，磁盘使用率到 100%，轻则上传失败、缓存写不进去，重则数据库进入只读、站点直接打不开。

磁盘吃紧时，站点会有哪些表现

• 页面打开变慢或直接返回 500，但重启服务后短暂恢复。
• 后台上传图片、发布文章失败，提示“写入失败”或“空间不足”。
• 数据库无法写入，评论、表单提交、订单全部卡住。
• 日志文件不再更新，排查问题时看不到最新记录。
• SSH 登录后命令补全变慢，甚至无法创建临时文件。

如果你遇到其中两三条，先别急着重启服务，登录服务器看一眼磁盘使用情况往往更直接。

先定位：哪些目录在占空间

用 df -h 查看各分区使用率，再用 du -sh 逐层排查大目录。常见“重灾区”包括：

• 访问日志与错误日志：Nginx、Apache、PHP、Node.js 等服务的日志目录。
• 数据库日志：binlog、慢查询日志、错误日志，尤其是未设置过期时间的 binlog。
• 应用临时文件：上传临时目录、缓存目录、会话文件、队列失败重试文件。
• 本地备份：自动备份脚本把压缩包留在同一块盘上，越积越多。
• 容器日志：Docker 默认 json-file 日志如果不限制大小，可能长到几个 GB。

定位时不要只看总大小，也要看文件数量和最近修改时间。一个几十 GB 的旧备份和一个正在快速增长的日志文件，处理方式并不一样。

日志轮转：别让单个文件无限追加

大多数 Linux 发行版自带 logrotate，但默认配置未必覆盖你的应用日志。自查时重点看几项：

• 是否按天或按大小切割？只按天切割，遇到突发流量仍可能一天写满。
• 保留多少份？保留 30 份还是 7 份，直接决定长期占用。
• 是否压缩旧日志？compress 和 delaycompress 能明显减少占用。
• 切割后是否通知服务重新打开日志文件？否则进程可能继续写已经改名的文件。

修改配置后，建议先用 logrotate -d 做一次调试运行，确认切割、压缩、删除顺序符合预期，再交给定时任务。

不要直接删除正在写入的日志文件。进程仍持有文件句柄，磁盘空间不会立即释放。更稳妥的做法是用 logrotate 切割，或者用 truncate 清空。

清理之外，还要留出缓冲

清理只能解决当下问题，运营上还需要一些缓冲策略：

• 系统盘和数据盘尽量分开，避免日志把系统盘写满导致服务异常。
• 给磁盘使用率设置监控告警，比如 80% 提醒、90% 告警，别等到 100% 才处理。
• 备份文件定期归档到对象存储，本地只保留最近几份，并设置生命周期规则。
• 容器日志配置大小上限和保留数量，避免单个容器日志失控。
• 定期检查自动任务产生的临时文件，尤其是导出、转码、爬虫抓取类任务。

磁盘空间自查不需要每天做，但应该纳入每周或每月的运维清单。花几分钟看一眼趋势，比半夜被报警叫醒要从容得多。