datastore 已告警或備份任務開始失敗？
最快的處理方式：先查 prune 與 GC 的排程、執行結果，再比對 PBS datastore 和底層儲存用量；不要只看快照清單或去重數值，也不要手動刪除 .chunks。
獨立維護 PBS 的管理員，可按下文區分任務問題與磁碟問題。
同時維護多個客戶環境的 MSP，應把保留策略、任務記錄與容量告警分開核對。
規劃多租戶備份儲存的小型 IDC，則可用這套流程判斷是否要重新估算容量與備份目標。
最後更新於 2026 年 10 月 28 日；版本與維護資訊核對自 Proxmox Backup Server 4.2 官方發布說明及 PBS 4.2 官方維護文件。
先分辨任務異常與容量告警
Proxmox Backup Server 4.2 於 2026 年 4 月 29 日發布，版本資訊以官方發布說明為準。遇到 PBS 4.2 datastore 滿盤處理問題，先將「任務有沒有照預期執行」與「底層儲存是否真的沒有空間」拆開查，避免把告警直接當成刪除資料的理由。
快照項目、去重資訊與檔案系統用量代表不同狀態。移除一個快照後，某些資料區塊仍可能被其他備份使用；未再被參照的區塊，也不表示磁碟會在 prune 結束時立刻回收。你需要分別取得 prune 記錄、GC 記錄和底層儲存狀態，才有足夠資訊決定下一步。
請先留下告警時間、受影響的 datastore、最近一次備份結果，以及相關任務記錄。若這是多客戶共用的維護環境，先確認變更涉及哪些客戶和保留規則，未經確認不要執行可能移除備份的操作。
按運維責任整理檢查重點
單台 PBS 的管理員，先核對 prune 和 GC 是否有排程、近期是否成功，以及錯誤訊息是否指向任務未執行、執行失敗或儲存不足。再比對 datastore 狀態與實際掛載點用量；不要把快照數量或去重比例直接換算成可釋出的磁碟空間。
維護多套客戶環境的 MSP，需要額外保留任務時間、錯誤記錄、客戶對應的保留政策，以及任何已核准的變更紀錄。這樣才能分清楚是某個環境的 prune 設定不符預期，還是共用儲存位置的空間告急；在原因未明時，不要對多客戶資料執行批次清理。
管理多租戶備份存儲的小型 IDC，應先確認 datastore 的實際儲存邊界與告警來源，再逐一檢視受影響的租戶、備份任務和可用容量。若客戶共用同一個儲存池，單看 PBS 中一個 datastore 的摘要不足以判斷其他資料是否也受影響。
PBS 4.2 的 datastore 與維護方式，應依官方儲存文件和官方維護文件核對。官方論壇在 2026 年 9 月 22 日有一則滿盤討論，但這只是社群個案，不能據此推論 PBS 4.2 普遍存在滿盤缺陷，也不應把個別回覆中的臨時操作當成通用修復方法。查看該社群個案
依序核對 prune、GC 與儲存用量
以下步驟先收集狀態，再選擇處置；前段的檢查不會要求你直接刪除備份資料。
- 記錄告警與影響範圍。 記下 datastore 名稱、告警時間、最近一次成功備份時間，以及受影響的租戶或系統。保存 PBS 任務記錄，避免後續清理覆蓋原始線索。
- 核對 prune 排程和結果。 在 PBS 管理介面查看相關工作是否啟用、最近執行時間與任務結果，再比對保留規則是否符合預期。不要因為快照仍顯示在清單中，就直接判定排程失效。
- 核對 GC 狀態和錯誤記錄。 確認 GC 任務是否成功、尚未完成或根本未執行，並查看是否有儲存錯誤。不要在工作狀態不明時反覆啟動維護任務。
- 確認 datastore 的實際後端與掛載點。 先辨認是 ext4、XFS、ZFS，還是依 PBS 文件設定的 S3 datastore。Linux 主機可用
findmnt -T /datastore/路徑確認路徑對應的掛載點；將路徑替換成實際位置，不要照抄示例路徑。 - 查看底層用量與可用空間。 對本機檔案系統，可用
df -hT /datastore/路徑查看容量與檔案系統類型，並以df -i /datastore/路徑檢查 inode 用量。若為 ZFS，還要用該儲存池的管理工具核對池與資料集狀態；若為 S3 datastore，不要把本機df結果當作物件儲存容量。 - 按照原因選擇處置。 若 prune 未執行，先查排程與任務錯誤；若 GC 尚未完成但仍能執行，先查明狀態與後端健康；若檔案系統確實不足，才評估安全釋放空間或擴容。
- 變更後重新驗證。 查看 prune、GC 和底層儲存的最新狀態，再確認後續備份是否按排程完成。若容量問題仍在，不要以一次成功的任務結果取代持續監控。
PBS 的管理工具和命令參數可能依版本與操作而異；在執行任何會變更資料的命令前，先核對官方命令參考。上面的 findmnt 與 df 用於檢查，不是修復指令。
.chunks；論壇上的個案建議也不能取代與你使用的儲存後端相符的官方處理方法。用後端狀態決定檢查方式
| datastore 儲存後端 | 優先核對的狀態 | 判讀限制 |
|---|---|---|
| ext4 或 XFS | PBS 任務結果、掛載點及 df -hT、df -i 顯示的檔案系統用量 |
df 的結果是檔案系統視角，不能單獨說明哪些備份資料可以刪除。 |
| ZFS | PBS 任務記錄，以及儲存池、資料集與掛載點的用量 | 池或資料集的用量不等於可移除的備份區塊；請按實際配置判讀。 |
| S3 datastore | PBS datastore 狀態、任務記錄與物件儲存端的容量或錯誤資訊 | 不適用本機路徑的 df 判讀；設定與維護方式須依 PBS 文件及實際後端核對。 |
依故障狀態選擇處理順序
| 查到的狀態 | 優先處理 | 避免的做法 |
|---|---|---|
| prune 未執行或失敗 | 查排程、錯誤記錄與保留規則，確認原因後再修復任務 | 只因快照數量多便直接刪除資料 |
| prune 已完成，GC 尚未完成但仍可執行 | 查 GC 狀態、錯誤記錄與後端健康，再按維護文件處理 | 把 prune 完成當成磁碟空間已回收 |
| 檔案系統或後端確實沒有足夠空間 | 查明受影響的儲存範圍、備份風險與可用恢復路徑，再評估釋放空間或擴容 | 未確認後端便套用其他環境的操作 |
| 空間不足，GC 或其他維護工作已無法運行 | 優先確保資料安全與可恢復性，依該後端的官方說明處理容量問題 | 手動刪除或搬移 .chunks，或假設擴容後必定自動恢復 |
這張表用來縮小排查範圍，不保證特定處置一定能釋出空間。若你仍無法確認資料風險或儲存後端，先停止破壞性變更並保存任務記錄，再確認恢復條件。
修復後重新估算容量
完成處置後，逐項確認 PBS datastore 狀態、底層儲存用量、prune 與 GC 任務結果，並查看後續備份是否成功。若告警再次出現，保留新一輪任務記錄，和處置前的紀錄對照，而不是只看一個容量數字。
估算未來空間時，將既有備份佔用、保留規則下持續新增的資料、資料變更量，以及儲存後端的實際可用容量分開評估。使用自己的備份歷史與增長趨勢，不要拿論壇個案或其他環境的增長率推算你的需求。多租戶環境還要分清租戶用量與共享儲存邊界，避免以單一租戶的短期數據代表整體需求。
完成下列檢查後，才將事件標記為已處理：
- [ ] 已保存告警與相關 PBS 任務記錄。
- [ ] 已確認 prune 排程、保留規則及最近執行結果。
- [ ] 已確認 GC 狀態，並查閱對應錯誤記錄。
- [ ] 已確認 datastore 的實際儲存後端與容量視角。
- [ ] 已按後端核對底層用量，沒有把快照或去重數值當成可刪空間。
- [ ] 任何清理或擴容變更都有明確的資料風險與恢復條件。
- [ ] 修復後已重新核對任務結果及後續備份狀態。
讓備份目標容量符合實際責任
如果你在共享 VPS 或公有雲執行 PBS，應先確認虛擬機可用磁碟是否有固定上限、磁碟與流量費用如何計算，以及你能否自行選擇儲存配置；不同方案的限制不一，需以實際合約與產品說明為準。若備份長期增長、需要更明確掌握硬體資源，獨享 AMD 物理伺服器可作為另一種備份目標選項；但你仍須自行規劃磁碟冗餘、機外備份、監控與維護，租用伺服器不等於託管備份服務。
你可以先依照自己的備份增長、保留策略與儲存後端核對容量，再查看 OVN Cloud 的伺服器配置選項和計費週期說明，以當期產品資料比較是否適合改用獨享目標。若現有環境仍能安全滿足容量與維護需求，就先修正任務或調整容量規劃；若共享方案的磁碟選擇或資源邊界已不符合你的備份責任，再考慮租用 OVN Cloud AMD 物理伺服器。
常見問題
刪除快照為什麼沒有立即釋出磁碟空間？
prune 整理的是符合保留條件的快照；快照使用的資料區塊可能仍被其他備份參照。GC 才會處理已沒有參照的區塊，實際用量變化還要從底層儲存後端核對，因此不能只根據快照列表判斷清理是否生效。
prune 和 GC 的工作差異是什麼？
prune 依保留規則決定要保留哪些備份快照，GC 則處理不再被備份參照的資料區塊。兩者作用不同，應分別查看排程和任務結果；prune 成功不代表 GC 已完成，也不保證磁碟用量立即下降。
datastore 快滿時，該先清理還是擴容？
先查明 prune、GC 的狀態和儲存後端的實際用量。若任務未執行或失敗，先確認原因；若後端空間確實不足，再根據官方文件、現有備份風險和恢復條件，評估安全釋放空間或擴容。
磁碟空間不足，GC 無法執行時怎麼辦？
不要手動刪除或搬移 .chunks。先確認 datastore 後端、任務記錄、備份資料風險與恢復路徑，再採用適用於該後端的官方處理方式。若進行擴容或其他儲存變更，之後仍要重新核對 GC、datastore 及後續備份結果。
常見問題
- 為什麼刪除 PBS 備份後，硬碟用量看起來沒有下降？ prune 移除的是符合保留條件的備份快照項目；其中的資料區塊仍可能被其他備份參照，未被參照的區塊也要由 GC 按維護機制處理。請分別查看 prune 任務結果、GC 狀態和底層檔案系統用量，不要只看快照清單便認定刪除失敗。
- PBS 的 prune 和 GC 各自負責什麼？ prune 依保留規則整理備份快照，決定哪些快照不再保留；GC 則掃描 datastore，處理已沒有備份參照的資料區塊。兩者不是同一個任務，因此 prune 成功不代表磁碟空間會立即回升；要確認實際結果，還需查看 GC 任務記錄與儲存後端的用量。
- datastore 快滿時，我應該先清理還是擴容？ 先確認 prune 是否按預期執行、GC 是否成功，以及檔案系統或儲存後端是否真的接近容量上限。若只是排程未執行或任務失敗，先查明並修正原因；若底層容量確實不足，再依後端文件和備份風險評估安全釋放空間或擴容。
- PBS 磁碟已滿，GC 無法執行時怎麼處理？ 不要手動刪除或搬移 .chunks。先保留工作記錄，確認 datastore 所在後端、可用的恢復路徑與現存備份風險，再依該後端和 PBS 官方文件處理空間不足問題。若需擴容，完成儲存變更後再檢查 GC、datastore 狀態及後續備份結果；不要假設單一操作必定能恢復服務。