在法國用 Docker 跑自架服務，磁碟滿了先查這三處

在法國租的 VPS 是 2 vCPU / 4 GB / 80 GB 的方案，系統是 Debian 12，Docker 版本是 24.0.7。平常跑著一個 Nextcloud、一個 Gitea 和一個小型 PostgreSQL，磁碟用量一直維持在六成左右。上週五早上收到監控告警，說根分割區剩不到 2 GB，SSH 進去 df -h 一看，/var/lib/docker 佔了 52 GB，比我預期多出快一倍。

先說我實際做的順序。第一步不是急著 docker system prune，而是先把每個容器的日誌大小列出來：

du -sh /var/lib/docker/containers/*/*-json.log | sort -h | tail -5

結果 Nextcloud 那個容器的 json.log 有 11 GB。原因是它的 log driver 還是預設的 json-file，沒有設上限，而那段時間我在測同步，Client 一直重試，錯誤訊息全寫進去了。我當下先截斷，而不是直接刪檔：

truncate -s 0 /var/lib/docker/containers/<id>/<id>-json.log

第二步才是看 volume。docker system df -v 會列出每個 volume 的大小，我發現有兩個已經沒有容器引用的 volume，是之前測試 Gitea 備份留下的，加起來 6 GB。確認過內容不重要之後才 docker volume rm。第三步才處理 image，docker image prune -a 清掉沒有 tag 引用的舊映像，又拿回 9 GB。

為什麼要照這個順序？因為 prune 是破壞性的、不可逆的，而日誌截斷和 volume 檢查是可逆或至少可確認的。Docker 的預設 log driver 沒有輪替，容器跑得越久日誌越大，這在小型 VPS 上很容易被忽略。代價是你要多花十分鐘確認，但少一次誤刪資料的風險。另外 docker system prune -a 會把沒在跑的映像全清掉，下次重建容器要重新拉，在法國這種頻寬不算便宜的地方，這點也值得考慮。

會失效的地方：如果你的日誌是送到 journald 或外部收集器，上面那條 du 就找不到東西，要改看 journalctl --disk-usage。另外，我踩過的坑是以為 docker system df 的數字是即時的，其實它對 volume 的統計有時候會落後，實際大小還是要用 du -sh 對照。還有一次 truncate 之後容器沒有重啟，log driver 的檔案描述符還開著，空間沒有立刻釋放，得重啟容器才看得到效果。

現在我把 daemon.json 加上了 log 輪替，重啟 docker 之後才生效：

{
  "log-driver": "json-file",
  "log-opts": { "max-size": "50m", "max-file": "3" }
}

想問一下：你們在法國的 VPS 上，日誌是留在本機輪替，還是直接丟到外部的收集器？我現在只有一台機器，還在猶豫要不要為此多開一個服務。