站点跑上一段时间后，访问日志、错误日志、缓存文件和临时文件会慢慢堆积。磁盘写满时，轻则后台打不开、图片上传失败，重则数据库无法写入，整站返回 500。这类故障很少毫无征兆，通常提前几天甚至几周就有信号。
磁盘写满前的几个信号
- 后台操作变慢，保存文章偶尔失败；
- 日志里开始出现 No space left on device、disk quota exceeded 之类的关键词；
- 图片或附件上传到一半报错；
- 数据库连接正常，但写入失败；
- 面板或监控图表里的磁盘占用曲线持续上扬，没有回落。
这些提示出现时，说明余量已经不多，最好当天处理，别拖到周末。
先看哪里最占空间
登录服务器后，按体积从大到小逐层排查，比盲目删文件安全得多。常用思路是先用 du -sh 看各目录总量，再进到最大的目录继续往下看。
- 网站根目录下的日志文件夹，尤其是按天生成的 access.log、error.log；
- 缓存目录与临时目录，比如框架生成的 cache、tmp；
- 备份文件，本地留一份、异地留一份就够，不要堆几十份；
- 上传目录，检查是否有异常大的文件或重复文件；
- 数据库文件与慢查询日志；
- 系统日志，如 /var/log 下的 messages、syslog、auth.log。
日志保留多久合适
日志既是排查故障的依据，也是分析蜘蛛抓取行为的数据源。直接清空虽然立刻腾出空间，但之后想回看某天的抓取情况就没有依据了。比较稳妥的做法是设一个保留窗口：
- 访问日志保留 30 到 90 天，覆盖一次完整的内容更新周期；
- 错误日志可以留得更久，因为报错往往隔一段时间才复现；
- 超出窗口的日志先压缩归档，压缩后仍占空间就转移到别的机器或对象存储；
- 归档文件也要定期清理，别让“归档”变成另一个垃圾桶。
不少服务器面板自带日志轮转功能，配置好按天切分和保留份数即可，不必手工删。
把自动清理配置起来
手工清理只能救急，长期还是要靠自动任务。可以写一个简单的脚本，用 find 按修改时间删除过期日志，或者用系统自带的日志轮转工具配置保留份数。配置完成后建议先手动执行一次，确认删除范围符合预期，再放进计划任务。
删除操作前先确认路径，尤其是带通配符的命令。写成 rm -rf /var/log/* 和写错一个字符的后果可能完全不同，能先备份就先备份。
顺手加一个容量告警
与其等访客反馈打不开，不如让监控提前告诉你。大部分可用性监控都支持磁盘占用阈值告警，设在 80% 到 90% 之间比较合适，既留出处理时间，也不至于频繁误报。
还可以把日志分析、备份核对、空间检查放进同一个维护节奏：每月固定一天看磁盘占用、确认日志轮转正常、验证备份是否可恢复。这些动作本身不复杂，难的是持续做下去。
蜘蛛池、URL 发现这类工作能开展的前提，是站点本身稳定可访问、日志能被正常记录。服务器先活着，后面的抓取与收录分析才有意义。