2026.11.09

Linux 日誌佔滿磁碟？用 journalctl 找出容量與安全保留方式

伺服器磁碟空間不足時，systemd journal 可能是需要檢查的一項，但不能看到大型日誌就直接刪除。日誌可能是故障調查或稽核所需的證據。先確認實際使用量、保存位置和保留需求，再決定是否清理。

先確認是哪個檔案系統滿了

df -hT
df -i
sudo journalctl --disk-usage
sudo journalctl --list-boots

df -hT 顯示檔案系統容量，df -i 顯示 inode。--disk-usage 統計目前 journal 的作用中與封存檔，不包含所有應用程式文字日誌。它若只占少量空間，就應繼續調查其他資料，而不是清除 journal。

再用服務名稱和時間縮小範圍，例如以下只讀查詢：

sudo journalctl -u nginx.service --since "2026-11-01 00:00:00" --until "2026-11-02 00:00:00" --no-pager
sudo journalctl -p warning -b --no-pager

服務名稱及時區依系統而異，輸出可能含使用者資料或其他敏感資訊。大量錯誤訊息應先處理根因；單純刪日誌無法阻止快速再次寫滿。

釐清暫存與永久保存

journald 可能使用 /run/log/journal 的暫存空間，或使用 /var/log/journal 永久保存；實際受 Storage 設定與目錄狀態影響。查看系統設定及發行版文件，不要假設每台主機都保留跨開機紀錄。若有集中式日誌平台，也要確認轉送與保留是否正常。

確認保留需求後才清理

先確認組織保存期限、事故調查及備份要求；必要時將相關紀錄匯出至受保護、容量足夠的其他位置並驗證可讀。以下命令會永久刪除較舊的封存 journal，只有在確認可刪除超過 30 天的封存紀錄後才執行：

sudo journalctl --vacuum-time=30days
sudo journalctl --disk-usage
df -hT

清理只作用於封存檔，作用中的檔案仍會計入使用量，因此清理後可能沒有降到預期值；也不應為了達到數字而直接刪除活動日誌。刪除後無法靠反向指令復原，必須仰賴事先保存的備份。

規劃長期上限與驗證

可依作業系統版本與保存政策評估 journald 的 SystemMaxUse=、SystemKeepFree=（永久日誌）或 RuntimeMaxUse=（暫存日誌）。先備份現有設定、確認 drop-in 優先順序，並在維護時段依發行版文件套用；限制主要透過移除舊封存檔達成，並非保證總用量永不超標。

變更後檢查 journald 服務狀態、日誌是否繼續寫入、磁碟容量與集中式轉送。若不符合預期，還原原設定並依發行版程序重新套用；已刪除日誌仍需從備份找回。官方參考：journalctl、journald.conf。網站異常時也可搭配外部 HTTPS 檢查，但外部檢查不能取代伺服器日誌。