很多人排查网站故障时习惯从代码和网络入手，却忽略了一个很朴素的前提：服务器还有没有空间可写。磁盘写满不会提前打招呼，它通常以一堆看似无关的小毛病出现——后台保存失败、图片上传报错、缓存生成不了、数据库突然变成只读。等页面开始大面积报错，往往已经晚了。
磁盘满时，站点通常有哪些表现
这些现象单独看都不像磁盘问题，但同时出现两三个，就值得先去看一眼剩余空间：
- 后台发布、保存、上传动作失败，但前端页面还能打开。
- 页面缓存不生成，访问变慢，命中率突然掉下来。
- 数据库提示无法写入，或者干脆进入只读状态。
- 日志文件停止增长，或者反过来，某个日志异常膨胀。
- 会话无法保存，用户频繁掉登录。
先确认：是真的满了，还是别的毛病
登录服务器用 df -h 看各分区使用率，再用 du -sh 从根目录一层层往下找。有两个细节容易被漏掉：一是 inode 也可能被耗尽，小文件特别多的站点很常见，需要用 df -i 检查；二是要看清到底是哪个分区满，很多环境把系统目录、数据目录和上传目录分开挂载，网站所在分区未必是问题所在。
空间通常被谁吃掉了
- 日志：访问日志、错误日志、应用日志、容器标准输出，没有切割时会一直堆下去。
- 备份文件：本地保留多份全量备份，尤其是数据库和上传目录，这是最常见的隐形大头。
- 上传与附件目录：用户上传内容、图片的多份副本、编辑器产生的临时文件。
- 缓存与临时目录：页面缓存、缩略图、包管理器缓存、临时会话文件。
- 数据库文件：数据量自然增长、日志未清理、长期没有维护的表。
- 系统与运行时：旧内核、容器镜像与悬空层、没清理的软件包缓存。
一套可以照着做的自查步骤
- 用 df -h 和 df -i 确认是哪个分区的容量或 inode 先接近上限。
- 从上层目录逐层 du -sh，通常两三步就能定位到具体目录。
- 把占用分成两类：必须保留的（备份、数据库）和可以清理的（过期日志、缓存）。
- 记录下当前占用数值，作为下次对比增长趋势的基线。
- 把结论落成动作：加日志切割、调整备份策略、迁移上传目录、设置定时清理。
清理时最容易踩的坑
不要直接删除正在被写入的日志文件。进程仍然持有文件句柄，空间不会马上释放，看起来删了却一点没腾出来。更稳妥的做法是清空文件内容，或者交给日志切割工具统一管理。
另外几点同样重要：删除备份之前，先确认最近一次恢复演练是成功的；清理缓存目录之前，确认站点能承受重新生成缓存时的负载；不要为了省空间去关掉数据库的必要日志，那是在用更大的风险换一点空间。
比清理更重要的是别再被写满
- 给关键分区设置使用率告警，阈值放在 80% 左右，留出处理时间。
- 日志按天或按大小切割，同时设置保留份数与压缩。
- 备份尽量落到异地或对象存储，本地只留最近一两份。
- 上传目录、缓存目录单独挂盘，避免和系统盘抢空间。
- 把磁盘与 inode 使用率写进常规巡检，而不是等出事才看。
小结
磁盘空间属于那种平时没人关注、出事却很致命的基础项。它更像个需要定期清理的房间，而不是装完就不用管的仓库。把它纳入日常巡检清单，成本很低，但能挡掉相当一部分莫名其妙的线上故障。