很多站点运营问题看起来是“程序 bug”，追下去却是磁盘满了。服务器不会在空间充足时提醒你，等到写入失败，访客看到的是 500，后台看到的是各种报错，蜘蛛抓取也会因为响应异常而降低频率。把磁盘和日志纳入日常自查，比事后救火省力得多。
磁盘被写满时，站点会出现哪些信号
不同程序表现不一样，但通常有一些共同点：
- 图片、附件上传失败，提示“无法写入”或“移动文件失败”。
- 后台登录正常，但保存文章、修改设置时报数据库错误。
- 页面间歇性返回 500 或 503，刷新后又可能恢复。
- 缓存文件写不进去，页面加载变慢或样式错乱。
- 数据库停止写入，甚至无法启动。
- 蜘蛛抓取日志里出现大量 5xx，抓取量随之下降。
如果同时出现上传失败和数据库报错，优先检查磁盘使用率，而不是先改代码。
常见的空间占用来源
1. 访问日志与错误日志
访问日志、错误日志、PHP 慢日志、数据库慢日志都会持续增长。流量越大、爬虫抓取越频繁，日志增长越快。有些服务器默认不做轮转，几个月就能占掉几十 GB。
2. 临时文件与缓存
程序生成的缩略图、编译模板、会话文件、对象缓存转存文件，如果只增不减，也会慢慢堆积。部分缓存目录在异常中断后会残留大量碎片文件。
3. 本地备份与导出文件
数据库导出、整站打包、插件生成的备份，常常被放在网站根目录或服务器本地。一个几 GB 的备份文件既占空间，又可能被外部访问到，属于安全和容量的双重隐患。
4. 数据库日志与二进制日志
MySQL 的 binlog、慢查询日志、中继日志如果不设保留周期，会长期占用空间。主从环境里，binlog 还可能因为复制延迟而积压。
5. 上传目录与垃圾文件
用户上传后未清理的临时图片、编辑器粘贴产生的重复附件、被删除文章遗留的媒体文件，都会留在 uploads 目录里。它们不一定影响访问，但会持续吃空间。
清理前的检查步骤
- 先用 df -h 看分区使用率，再用 du -sh 从根目录逐层定位大目录。
- 确认要清理的目录属于日志、缓存还是备份，避免误删正在使用的数据文件。
- 把备份文件先下载到本地或对象存储，确认可恢复后再删除服务器上的副本。
- 清理日志时优先使用轮转和截断，而不是直接删除正在写入的文件。
- 清理后复查服务状态、上传功能和数据库连接。
设置保留周期，比反复手动清理更可靠
手动清理只能解决当下问题。更稳妥的做法是给每类文件设定保留周期：
- 访问日志保留 7 到 30 天，按天轮转并压缩。
- 错误日志保留 30 天，方便回溯偶发问题。
- 本地备份只留最近 1 到 2 份，并且每日同步到异地。
- 缓存目录定期清理，或设置程序自动回收。
- 数据库 binlog 按空间和天数双重限制，避免无限增长。
这些周期没有统一标准，取决于服务器容量和业务需求，关键是写进维护计划并真的执行。
加一个简单的容量提醒
不需要复杂的监控系统，先用一条定时任务检查磁盘使用率即可。比如使用率超过 80% 时发邮件或消息提醒，超过 90% 时告警。这样可以在写入失败之前介入，而不是等访客和蜘蛛先发现问题。
磁盘容量不会像代码错误那样立刻暴露，但一旦写满，影响面往往覆盖前台、后台和数据库。把它纳入例行检查，属于成本低、收益稳定的基础维护。
几个不要做的操作
- 不要直接删除正在写入的日志文件，可能导致进程句柄异常。
- 不要在未确认备份可用的情况下清空数据库日志。
- 不要把备份放在网站根目录并提供公开下载。
- 不要为了腾空间删掉程序依赖的临时目录结构。
- 不要只看总容量，忽略 inode 被小文件占满的情况。
站点运营里的很多问题，最后都会落到服务器基础状态上。磁盘和日志清理不是一次性任务，而是需要定期复查的习惯。把使用率、保留周期和清理记录固定下来，出现异常时才有余力处理真正复杂的问题。