PVE/PBS 備份排程與季度報告驗證機制

排程原則

• 在 PVE/PBS 的備份治理中，真正的風險通常不是「沒有備份」，而是「備份有做但不可用」或「備份排程持續干擾正式服務」。
• 行雲資訊在規劃時會先把復原點目標（RPO）/復原時間目標（RTO）、儲存吞吐與維護窗口放到同一張排程表，不讓備份作業與核心業務互相踩踏。

1. 先定義業務分級：將 VM 分為關鍵、重要、一般三層，對應不同備份頻率與保留天數。
2. 分批而非全量同時跑：避免單一時段啟動過多 snapshot/backup 任務，降低儲存 IO 峰值。
3. 避開業務尖峰：至少保留一個低風險窗口給重作業（大型 VM、資料庫節點），其餘工作分散到離峰。
4. 同步保留策略：PVE job 保留與 PBS prune 規則要一起設計，避免「前端保留太多、後端無法回收」。
5. 預留重跑空間：排程間距需容納失敗重試，不要讓重試與下一批任務直接碰撞。

驗證流程

1. 排程前檢查：確認 PBS datastore 可用容量、chunk 去重效率、網路延遲、目標節點負載與授權狀態。
2. 基準建立：記錄每個 job 的初始耗時、平均傳輸量、壓縮比例與失敗碼，作為後續偏差判斷基準。
3. 執行監控：同時監看成功率、任務耗時、IO wait、節點 load average、PBS garbage collection 影響。
4. 失敗分類：先分成排程衝突、儲存延遲、網路中斷、權限/認證失效四類，再對應處理 SOP，避免每次都從零排查。
5. 還原抽測：每月至少抽樣還原一台關鍵 VM，驗證備份不只「完成」，而且「可實際啟動並提供服務」。
6. 季度彙整：整理成功率、平均耗時、容量成長、失敗分布與改善項，作為容量與風險評估基準。

排程設計範例

1. 關鍵系統：每日 2-4 次備份，保留較短但密集，重點是降低資料遺失時間窗。
2. 一般系統：每日 1 次或每週多次，搭配較長保留週期，優先控制儲存成本。
3. 大型資料節點：單獨 job 與獨立窗口，避免拖慢其他 VM 備份。
4. Prune/GC 規則：與備份窗口錯開，避免在備份高峰同時執行垃圾回收造成 IO 競爭。

失敗處理 SOP

1. 先確認是否為單點事件：檢查同時段是否多台 VM 一起失敗，判斷是單 VM 問題還是整體基礎設施問題。
2. 查任務日誌與節點資源：從 PVE task log、PBS task log、節點 IO/CPU/記憶體指標交叉比對。
3. 判斷是否可立即重跑：若是短暫網路或瞬時負載可重跑；若是容量或儲存健康問題，先止血再重跑。
4. 更新排程或資源配置：把重複失敗案例回寫到排程規則（拆 job、改窗口、調整並發數）。
5. 留下事故紀錄：至少記錄發生時間、影響範圍、根因、處置與防再發措施，供季度回顧使用。

通知與紀錄

1. 即時通知：成功/失敗通知送到郵件或訊息機器人，失敗事件要附上 job 名稱、VM ID、錯誤碼與時間戳。
2. 日報摘要：每日產生備份摘要（成功率、失敗數、重跑結果），讓窗口快速掌握健康度。
3. 月度健康檢查：統計容量使用、耗時變化與失敗趨勢，提早處理將爆量的儲存池或異常節點。
4. 季度報告欄位：固定輸出成功率、還原抽測結果、容量趨勢、主要異常與下一季改善計畫。

參考資料

• Proxmox VE Backup and Restore
  https://pve.proxmox.com/pve-docs/chapter-vzdump.html
• Proxmox Backup Server Documentation
  https://pbs.proxmox.com/docs/
• Proxmox VE vzdump manual
  https://pve.proxmox.com/pve-docs/vzdump.1.html