服务器磁盘写满，通常不是一瞬间发生的。它更像一个慢慢积累的问题：日志文件每天增长、缓存目录越滚越大、旧备份忘了删、临时文件没人清理。等到磁盘使用率接近 100%，站点可能表现为响应变慢、图片加载失败、数据库无法写入，甚至直接返回 5xx。对访客来说这是事故；对搜索蜘蛛来说，连续抓取失败也会影响它对站点可用性的判断。把磁盘和日志纳入日常运营自查，比出事后再扩容更省心。
先看磁盘到底被什么占用
不要一上来就删文件。先确认空间去向，再决定处理方式。常用思路：
- 用 df -h 查看各分区整体使用率；
- 用 du -sh 逐层查看目录体积，找到增长最快的目录；
- 检查网站根目录、日志目录、缓存目录、备份目录、数据库数据目录；
- 留意是否有异常大的单文件，比如失控的日志、未清理的压缩包、导出文件。
知道谁占空间，后续清理才有依据，也能避免误删正在使用的文件。
日志不是越多越好
访问日志和错误日志对排查问题很有价值，尤其是分析搜索蜘蛛的抓取频次、状态码分布和抓取路径。但原始日志长期不清理，会占用大量空间。建议：
- 设置按天或按大小轮转，保留最近 7 到 30 天；
- 需要长期留存的日志，压缩后转移到其他存储；
- 错误日志单独保留，方便定位问题；
- 定期检查日志写入是否正常，日志突然不增长也可能是异常。
如果站点规模较大，可以在日志轮转后做一次摘要统计，把关键指标留存下来，原始文件就可以更放心地清理。
缓存、临时文件和旧备份
缓存能提升访问速度，但缓存文件也需要管理。插件缓存、页面缓存、图片缩略图、编译模板等目录，可能随着内容更新不断产生新文件。建议确认缓存是否有自动清理机制，或者设置定期清理任务。备份文件同样容易堆积：本地保留最近几份即可，历史备份应转移到对象存储或离线位置，不要长期放在同一块磁盘上。
数据库与附件也不要忽略
数据库体积增长可能来自 revisions、临时表、日志表、垃圾评论或无效订阅记录。可以定期检查各表体积，清理确认无用的数据。附件目录方面，要留意重复上传、未引用的图片、旧版本文件。删除前最好先导出清单，确认这些文件没有被页面引用，再批量处理。
设置阈值和告警
不要等磁盘 100% 才收到通知。可以在 70%、85%、90% 设不同级别告警，给自己留出处理时间。告警内容至少包括：哪台机器、哪个分区、当前使用率、增长趋势。如果能在磁盘增长异常时提前发现，很多故障可以避免。除了磁盘，还可以关注 inode 使用率，它和空间一样会导致无法写入。
清理前的安全习惯
- 先备份再删除，至少保留一份可恢复的副本；
- 确认文件不被程序占用，避免删除后服务异常；
- 不要手动删除正在写入的日志，优先用日志轮转工具；
- 用明确路径清理，而不是通配符乱删；
- 清理后观察一段时间，确认站点、数据库、图片访问正常。
把检查写进例行清单
可以每周或每月做一次简短检查：磁盘使用率、日志轮转是否生效、缓存目录体积、备份是否成功、数据库增长是否正常。把这些项目写进运营清单，比依赖记忆更可靠。对于有搜索蜘蛛抓取需求的站点，稳定的服务器响应是基础条件，而不是额外加分项。
磁盘和日志管理看起来是运维细节，但它直接影响站点能否稳定响应。稳定响应是访客完成访问、搜索蜘蛛持续抓取的前提。
站点运营不只是内容更新和栏目规划，服务器维护同样是日常的一部分。磁盘空间和日志管理不需要复杂工具，关键是定期看、提前处理、保留可恢复的余地。这样即使流量增长或日志变多，也不至于因为一块磁盘写满而让整个站点停摆。