很多站点运营問题看起来是“程序 bug”，追下去却是磁盘满了。服務器不會在空間充足时提醒你，等到寫入失敗，訪客看到的是 500，後台看到的是各種报错，蜘蛛抓取也會因為响應異常而降低频率。把磁盘和日誌纳入日常自查，比事後救火省力得多。
磁盘被寫满时，站点會出現哪些信号
不同程序表現不一样，但通常有一些共同点：
- 图片、附件上传失敗，提示“無法寫入”或“移動文件失敗”。
- 後台登入正常，但儲存文章、修改設定时报資料库错誤。
- 頁面間歇性返回 500 或 503，刷新後又可能恢复。
- 缓存文件寫不進去，頁面加载變慢或样式错乱。
- 資料库停止寫入，甚至無法啟動。
- 蜘蛛抓取日誌里出現大量 5xx，抓取量随之下降。
如果同时出現上传失敗和資料库报错，優先检查磁盘使用率，而不是先改代碼。
常见的空間占用来源
1. 訪問日誌與错誤日誌
訪問日誌、错誤日誌、PHP 慢日誌、資料库慢日誌都會持續增長。流量越大、爬虫抓取越频繁，日誌增長越快。有些服務器預設不做轮轉，几個月就能占掉几十 GB。
2. 临时文件與缓存
程序生成的缩略图、编译模板、會话文件、對象缓存轉存文件，如果只增不减，也會慢慢堆积。部分缓存目錄在異常中断後會残留大量碎片文件。
3. 本地备份與導出文件
資料库導出、整站打包、插件生成的备份，常常被放在網站根目錄或服務器本地。一個几 GB 的备份文件既占空間，又可能被外部訪問到，属于安全和容量的双重隐患。
4. 資料库日誌與二進制日誌
MySQL 的 binlog、慢查询日誌、中繼日誌如果不设保留周期，會長期占用空間。主從环境里，binlog 還可能因為複製延迟而积压。
5. 上传目錄與垃圾文件
用戶上传後未清理的临时图片、編輯器粘贴产生的重复附件、被刪除文章遗留的媒体文件，都會留在 uploads 目錄里。它們不一定影响訪問，但會持續吃空間。
清理前的检查步骤
- 先用 df -h 看分区使用率，再用 du -sh 從根目錄逐层定位大目錄。
- 確認要清理的目錄属于日誌、缓存還是备份，避免誤删正在使用的資料文件。
- 把备份文件先下载到本地或對象存储，確認可恢复後再刪除服務器上的副本。
- 清理日誌时優先使用轮轉和截断，而不是直接刪除正在寫入的文件。
- 清理後复查服務狀態、上传功能和資料库连接。
設定保留周期，比反复手動清理更可靠
手動清理只能解决当下問题。更稳妥的做法是给每類文件设定保留周期：
- 訪問日誌保留 7 到 30 天，按天轮轉並压缩。
- 错誤日誌保留 30 天，方便回溯偶發問题。
- 本地备份只留最近 1 到 2 份，並且每日同步到异地。
- 缓存目錄定期清理，或設定程序自動回收。
- 資料库 binlog 按空間和天數双重限制，避免無限增長。
這些周期没有统一标准，取决于服務器容量和业務需求，關键是寫進维護計划並真的执行。
加一個简單的容量提醒
不需要复杂的监控系統，先用一條定时任務检查磁盘使用率即可。比如使用率超過 80% 时發邮件或消息提醒，超過 90% 时告警。這样可以在寫入失敗之前介入，而不是等訪客和蜘蛛先發現問题。
磁盘容量不會像代碼错誤那样立刻暴露，但一旦寫满，影响面往往覆盖前台、後台和資料库。把它纳入例行检查，属于成本低、收益稳定的基础维護。
几個不要做的操作
- 不要直接刪除正在寫入的日誌文件，可能導致進程句柄異常。
- 不要在未確認备份可用的情况下清空資料库日誌。
- 不要把备份放在網站根目錄並提供公開下载。
- 不要為了腾空間删掉程序依赖的临时目錄结构。
- 不要只看總容量，忽略 inode 被小文件占满的情况。
站点运营里的很多問题，最後都會落到服務器基础狀態上。磁盘和日誌清理不是一次性任務，而是需要定期复查的习惯。把使用率、保留周期和清理记錄固定下来，出現異常时才有余力處理真正复杂的問题。