伺服器磁碟空間耗盡導致圖片上傳失敗：一個 df -h 就能查出的真實案例

早上上班收到報警：「Discuz!X 論壇無法上傳圖片」。追蹤程式日誌發現：檔案寫入臨時目錄正常，但從臨時檔生成正式圖片檔時中斷報錯。檢查權限、程式碼、覆蓋開發環境代碼均無異常。偶然發現同伺服器另一站點同樣報錯。查看 Apache 錯誤日誌提示「write failed: No space left on device」。一條 df -h 揭開真相：磁碟剩餘空間 0。原來是備份腳本跑滿了整顆磁碟。

故障時間線

關鍵指令速查

# 1. 快速檢視磁碟使用率 (人類可讀)
df -h

# 2. 找出佔用空間最大的目錄 (前 10)
du -h --max-depth=1 / | sort -hr | head -10

# 3. 找出指定目錄下大檔案
find /backup -type f -size +100M -exec ls -lh {} \;

# 4. 清理舊備份 (保留最近 7 天)
find /backup -type f -mtime +7 -name "*.tar.gz" -delete

# 5. 監控磁碟空間 (加入 crontab 每小時檢查)
df -h | awk 'NR>1 && $5+0 > 85 {print "Disk alert: " $0}' | mail -s "Disk Alert $(hostname)" admin@example.com

根因與教訓

• 備份無保留策略 / 保留過久： 每日全量備份疊加，未刪除歷史備份，最終填滿磁碟。
• 無磁碟空間監控告警： 事發前無任何通知，被動發現。
• 備份與業務共用同一磁碟： 備份爆發性增長直接擠佔業務寫入空間。
• 日誌未提示「磁碟滿」： 應用層日誌只記「寫入失敗」，未明確提示磁碟空間不足，誤導排查方向。

預防措施清單

1. 備份保留策略： 定義保留份數 (如每日保留 7 份、每週 4 份、每月 3 份)，腳本自動清理過期備份。
2. 備份隔離： 備份寫入獨立磁碟/網路儲存 (NAS/S3/OSS)，不與系統盤/資料盤共用。
3. 磁碟監控告警： Zabbix/Prometheus/自製腳本監控 disk.used.pct > 80% 即時告警 (郵件/釘釘/Telegram/簡訊)。
4. 應用層錯誤處理增強： 捕獲 ENOSPC (No space left on device) 時，明確記錄「磁碟空間不足」並拋出友善錯誤訊息給前端/日誌。
5. 定期演練： 季度模擬磁碟滿場景，驗證告警觸發、清理流程、業務恢復時間。

一條 df -h 省去數小時盲目排查。**磁碟空間耗盡是最隱蔽、破壞力最強、卻最容易預防的故障**。建立「備份保留 + 隔離儲存 + 主動監控 + 明確錯誤提示」四位一體防線，讓「No space left on device」永遠不再出現在生產日誌中。