Ubuntu 根目錄空間不足：從緊急止血到容量治理的處理手冊

根目錄空間不足不只是容量告警。當系統無法寫入暫存、日誌或套件資料時，服務可能停止、更新失敗，甚至讓資料庫與監控同時失去紀錄。處理原則是先確認影響、保存證據，再逐步釋放可安全回收的空間；不能看到大檔案就直接刪除。

適用場景與事件分級

收到根目錄使用率、剩餘空間或寫入失敗告警時適用。若核心服務已停止、檔案系統唯讀、剩餘空間持續快速下降，應提升事件等級並暫停非必要發布。若只是接近預警門檻且趨勢平穩，可在維護時段處理，但仍需找出成長來源，不能只清理後結案。

使用檔案系統容量工具確認是哪個掛載點不足，同時檢查 inode 是否耗盡；大量小檔案可能在容量尚可時就阻止新檔建立。確認根目錄與資料磁碟是否分開，避免誤判。記錄事件時間、使用率、服務狀態與最近變更，並保留處理前畫面或命令輸出，作為後續分析依據。

從根目錄下一層開始，使用限制在同一檔案系統的容量統計，逐層縮小到套件快取、系統日誌、應用日誌、暫存、容器資料或使用者檔案。避免一開始掃描所有網路掛載與虛擬檔案系統。若目錄統計與檔案系統用量明顯不符，檢查是否有檔案已被刪除但仍由執行中程序開啟。

不要只列出最大檔案，也要依修改時間判斷是否正在快速成長。結合日誌輪替、排程、備份與近期發布紀錄，找出「為何成長」，而不只是「什麼最大」。應用程式若持續大量寫入，先調降非必要記錄或暫停相關工作，防止剛釋放的空間立即被吃回去。

套件管理工具保留的下載快取通常可重新取得，可先查看占用再使用正式清理功能。移除不再需要的相依套件前，必須檢視清單，確認不會刪除業務服務需要的元件。核心套件也應透過套件管理流程處理，不要直接刪除系統檔案。

先查看日誌總占用與保留政策，再依時間或容量縮減。保留量應符合故障調查與法規需求，不能為了立即釋放空間而清空所有證據。若單一服務大量寫入，要修正日誌層級、輪替與壓縮設定，並確認輪替後服務能重新開啟檔案。

應用日誌需由服務擁有者確認保留與備份需求。暫存目錄也可能包含執行中工作，應依檔案年齡、擁有者與開啟狀態判斷。容器映像、停止容器與建置快取可透過平台提供的清理命令處理，但刪除前要確認沒有回復或稽核用途。

若程序仍持有已刪除檔案，檔案名稱雖消失，空間仍不會釋放。先辨識程序與服務影響，再透過受控重新啟動讓檔案描述元關閉。不要任意終止不明程序；資料庫與交易服務需依其正常停止程序操作，必要時安排故障轉移。

每完成一項動作就重新確認剩餘空間與服務狀態，避免一次執行多個清理後無法追蹤影響。確保套件管理、日誌寫入、監控代理與核心業務功能恢復正常。觀察一段時間的成長速度，確認空間沒有再次快速下降，再解除事件狀態。

建立多層門檻，除了使用率，也監控剩餘絕對容量、inode 與成長率。日誌設定輪替、壓縮、上限與集中保存；應用資料與系統磁碟適度分離。容量預測應納入發布、資料成長與保留政策。若需求本身合理成長，應擴充檔案系統或重新配置，而不是反覆人工清理。

誤刪系統、資料庫或尚未備份的檔案可能造成比容量不足更嚴重的事故。清空日誌會破壞調查證據；大量掃描也可能增加磁碟負載。只看百分比可能忽略大型磁碟仍有充足空間，或小型分割區即將耗盡的差異，因此門檻要結合絕對容量與成長速度。

磁碟事件處理的品質不在於刪得多快，而在於能否用最小風險恢復寫入能力並留下可追查證據。以確認範圍、定位來源、安全止血、逐步驗證與長期治理的順序處理，才能避免反覆告警與二次事故，並把一次救火轉化為容量管理制度。