很多人排查網站故障时习惯從代碼和網絡入手，却忽略了一個很朴素的前提：服務器還有没有空間可寫。磁盘寫满不會提前打招呼，它通常以一堆看似無關的小毛病出現——後台儲存失敗、图片上传报错、缓存生成不了、資料库突然變成只讀。等頁面開始大面积报错，往往已经晚了。
磁盘满时，站点通常有哪些表現
這些現象單獨看都不像磁盘問题，但同时出現两三個，就值得先去看一眼剩余空間：
- 後台發布、儲存、上传動作失敗，但前端頁面還能打開。
- 頁面缓存不生成，訪問變慢，命中率突然掉下来。
- 資料库提示無法寫入，或者干脆進入只讀狀態。
- 日誌文件停止增長，或者反過来，某個日誌異常膨胀。
- 會话無法儲存，用戶频繁掉登入。
先確認：是真的满了，還是別的毛病
登入服務器用 df -h 看各分区使用率，再用 du -sh 從根目錄一层层往下找。有两個细节容易被漏掉：一是 inode 也可能被耗尽，小文件特別多的站点很常见，需要用 df -i 检查；二是要看清到底是哪個分区满，很多环境把系統目錄、資料目錄和上传目錄分開挂载，網站所在分区未必是問题所在。
空間通常被谁吃掉了
- 日誌：訪問日誌、错誤日誌、應用日誌、容器标准輸出，没有切割时會一直堆下去。
- 备份文件：本地保留多份全量备份，尤其是資料库和上传目錄，這是最常见的隐形大头。
- 上传與附件目錄：用戶上传内容、图片的多份副本、編輯器产生的临时文件。
- 缓存與临时目錄：頁面缓存、缩略图、包管理器缓存、临时會话文件。
- 資料库文件：資料量自然增長、日誌未清理、長期没有维護的表。
- 系統與執行时：舊内核、容器镜像與悬空层、没清理的软件包缓存。
一套可以照着做的自查步骤
- 用 df -h 和 df -i 確認是哪個分区的容量或 inode 先接近上限。
- 從上层目錄逐层 du -sh，通常两三步就能定位到具体目錄。
- 把占用分成两類：必须保留的（备份、資料库）和可以清理的（過期日誌、缓存）。
- 记錄下目前占用數值，作為下次對比增長趋势的基线。
- 把结论落成動作：加日誌切割、調整备份策略、迁移上传目錄、設定定时清理。
清理时最容易踩的坑
不要直接刪除正在被寫入的日誌文件。進程仍然持有文件句柄，空間不會马上释放，看起来删了却一点没腾出来。更稳妥的做法是清空文件内容，或者交给日誌切割工具统一管理。
另外几点同样重要：刪除备份之前，先確認最近一次恢复演练是成功的；清理缓存目錄之前，確認站点能承受重新生成缓存时的负载；不要為了省空間去關掉資料库的必要日誌，那是在用更大的風險換一点空間。
比清理更重要的是別再被寫满
- 给關键分区設定使用率告警，阈值放在 80% 左右，留出處理時間。
- 日誌按天或按大小切割，同时設定保留份數與压缩。
- 备份尽量落到异地或對象存储，本地只留最近一两份。
- 上传目錄、缓存目錄單獨挂盘，避免和系統盘抢空間。
- 把磁盘與 inode 使用率寫進常規巡检，而不是等出事才看。
小结
磁盘空間属于那種平时没人關注、出事却很致命的基础項。它更像個需要定期清理的房間，而不是装完就不用管的仓库。把它纳入日常巡检清單，成本很低，但能挡掉相当一部分莫名其妙的线上故障。