服务器磁盘写满是那种平时没人注意、出事却很突然的故障。它不像代码报错会给出清晰提示，往往先是日志追加失败，接着缓存无法落盘，最后数据库拒绝写入、页面开始返回 5xx。对搜索引擎蜘蛛来说，它看到的只是站点持续不可用，抓取节奏会被打乱，恢复之后也需要一段时间才能回到原来的水平。
磁盘写满后，站点会依次出现什么
空间耗尽可能不是瞬间发生，而是一个逐步恶化的过程，表现往往按下面的顺序出现：
- 日志无法追加：排错线索中断，反而更难看清楚发生了什么。
- 会话与缓存写入失败：登录状态异常、页面片段读不到，用户会看到空内容或旧内容。
- 数据库转为只读或直接崩溃：动态页面开始大面积返回 5xx 或错误页。
- 静态资源生成失败：图片、缩略图、导出文件出现 404 或半截文件。
- 蜘蛛连续抓取失败：抓取频率下降，恢复后需要重新建立稳定印象。
哪些文件最容易把空间吃光
- 访问日志与错误日志：访问量大、报错多的站点，日志增长速度常常超出预期。
- 临时文件与上传缓存：上传中断、任务失败留下的碎片文件容易长期堆积。
- 数据库备份与导出文件：本地保留多份全量备份，很快就会占掉几十 GB。
- 站点自身生成的静态文件：缓存页面、图片裁剪副本、打包产物可能存在多份重复。
- 包管理器与系统缓存：依赖缓存、旧内核、旧版本安装包通常可以安全清理。
一次可执行的空间自查
不必等到告警才动手，按下面的顺序走一遍，基本能定位到主要占用者：
- 用 df -h 查看每个挂载点的使用率，先找出超过 80% 的分区。
- 进入占用最高的目录，用 du -sh * 逐层缩小范围，不要一上来就删。
- 单独检查日志目录，确认是否有单个文件异常膨胀。
- 检查数据库数据目录与备份目录，区分在线数据与冷备份。
- 检查 /tmp 与上传目录，清理长期未访问的碎片文件。
- 用 df -i 确认 inode 使用情况，避免容量够但索引节点耗尽。
容量够，也可能写不进去
当站点存在大量小文件时，比如会话文件、缓存碎片、按目录切分的静态页，inode 会比磁盘容量更早耗尽。此时 df -h 显示还有余量，但新建文件已经失败。把 inode 使用率一并纳入监控，能提前发现这类问题。
删除之前先确认三件事
- 文件是否被进程持有：正在写入的日志被直接删除，空间不会立即释放，通常需要重启进程或改用清空方式处理。
- 备份是否真的可用：删除前确认最近一份备份可以恢复，而不是只看到一个文件名。
- 是否影响回滚：旧版本包、旧静态目录如果还在回滚窗口内，就不要急着删。
把日志轮转和保留策略固定下来
比起定期手工清理，更省心的做法是让轮转规则自动执行：
- 按天或按大小切分日志，同时配置保留份数，超出后自动删除。
- 只按天切分不够，配合最大体积限制，防止突发流量把单日日志写到很大。
- 应用日志分级输出，生产环境避免长期开启调试级别。
- 错误日志可以比访问日志保留更久，方便回溯抓取失败和 5xx。
- 轮转后确认进程能重新打开日志文件，否则会出现写入到已删除文件的情况。
监控与告警的阈值设置
把磁盘和 inode 同时纳入监控，使用率到 80% 提醒，到 85% 升级为需要处理的事项，留出反应时间。除了容量指标，也可以对写入失败的关键字做日志告警，比如日志无法打开、缓存目录不可写。定期的邮件提醒之外，建议每周固定抽查一次增长趋势，看看哪个目录在持续变大。
磁盘空间和证书、解析一样，属于会直接影响蜘蛛能否正常访问的基础项。把它写进运维日历，按周看一眼趋势、按月做一次清理复核，比等站点停摆之后再排查要轻松得多。