Proxmox Backup Server 與 Veeam，虛擬機備份的增量與還原速度
在 VMware vSphere 上，這個追蹤機制叫做 CBT（Changed Block Tracking），由 ESXi 核心維護一份虛擬磁碟的變更位圖；在 Hyper-V 上則是 RCT（Resilient Change Tracking）。而在 Proxmox VE 上，QEMU/KVM 本身提供了 dirty bitmap 機制，PVE 6.x 之後的備份流程會透過它取得變更區塊，並在每輪備份結束後重設位圖。
這裡有個很重要的實務細節：CBT／dirty bitmap 的可靠性直接決定增量備份的可信度。如果位圖因快照鏈中斷、VM 遷移、儲存層快照還原而失效，備份軟體就必須退回全備份。這也是為什麼企業級方案會反覆強調「CBT 驗證」與「自動退回完整備份」的機制。我們的測試中，兩套方案都曾在刻意製造的異常情境（例如備份中強制關機、遷移 VM）後觸發一次全備份，這屬於預期行為，讀者不必因此視為缺陷。
二、參賽者介紹：PBS 與 Veeam 的架構差異
2.1 Proxmox Backup Server：內容定義式儲存帶來的天生優勢
PBS 是 Proxmox 官方推出的備份伺服器，2020 年首次釋出，目前穩定版為 3.x 系列。它最大的特色是採用內容定義式區塊儲存（content-addressed chunk store）：每個備份資料流會被切成固定大小的區塊（依設定，一般為 4 MB 級別），每個區塊計算 SHA-256 雜湊值後存檔，重複的區塊只存一份。
這個設計帶來幾個直接後果。第一，跨 VM、跨時間點的重複資料會自動去重，即使你在不同 VM 上安裝同一套 Windows Server，系統檔的區塊也只會被存一次。第二，增量備份不需要「完整備份鏈」的概念，每個快照都是獨立可讀的索引，指向共用區塊池，因此沒有傳統「合成式完整備份」那種耗時的合併作業。第三，垃圾回收（Garbage Collection）與驗證（Verify）成為日常維運的一部分，需要獨立排程。
另一個很容易被忽略的優點是：PBS 原生就是 Proxmox VE 的儲存後端，PVE 可以直接把 PBS 掛成一個 storage type，備份、還原、排程全部在 PVE 介面完成，不需要額外代理程式或 Windows 主機。這種「原生整合」在小型團隊中是巨大的維運優勢。
2.2 Veeam Backup & Replication：映像鏈與變更區塊追蹤的成熟體系
Veeam 從 2008 年的 Veeam Backup & Replication 起家，如今已是企業備份市場的指標產品。其核心設計是映像級備份（image-level backup）：透過 hypervisor 的 API 取得 VM 快照，再以 CBT/RCT 擷取變更區塊，寫入備份儲存庫（Repository）。
Veeam 的備份鏈設計相當有彈性，常見模式包括：
合成式完整備份的速度，很大程度取決於儲存檔案系統。若 Repository 使用 ReFS 或 XFS，可啟用區塊複製（Block Cloning / Fast Clone），合成動作幾乎是瞬間完成，不產生實際資料搬移。這是 Veeam 在 Windows/Linux 環境中非常關鍵的效能優勢，也是許多評測忽略的重點。
此外，Veeam 支援應用程式感知（VSS、Oracle RMAN、SQL Server 交易記錄備份）、SureBackup 自動驗證、Instant Recovery 即時還原、以及跨平台遷移（VMware ↔ Hyper-V ↔ Nutanix AHV），這些是 PBS 目前無法企及的功能深度。需要補充的是，Veeam 12.2 起已加入對 Proxmox VE 的支援，這對混合環境使用者是重要利多，但成熟度與功能覆蓋仍不及在 vSphere 上的表現，讀者選型時務必實測。
2.3 授權與成本結構的現實考量
PBS 是開源專案（GPLv3），企業版訂閱主要提供技術支援與企業套件，沒有「每台 VM 計價」的概念，對 VM 數量多但預算有限的團隊極具吸引力。Veeam 則採訂閱或永久授權，通常以「每台 VM」或「每個工作負載」計價，功能分級（Foundation / Advanced / Enterprise Plus）明顯。
我們的測試環境中，同樣保護 30 台 VM，PBS 僅需一台實體主機加上儲存；Veeam 則需要一台 Windows 主機作為備份伺服器、至少一個 Repository，加上授權費用。若把三年 TCO 攤開，差距相當可觀。不過，若企業已經身處 vSphere 生態、或需要跨平台與應用程式感知備份，Veeam 的授權費往往被認為「花得值得」。
三、測試環境與方法論
3.1 硬體與軟體組態
為避免「拿不同等級的硬體比效能」這種常見的評測錯誤，我們刻意讓兩套方案在相同網路與相同等級的儲存上運行，差異僅在於各自的原生平台。
項目
Proxmox VE + PBS 環境
VMware + Veeam 環境
虛擬化主機
3 節點 Dell PowerEdge R750（同規格）
虛擬化平台
Proxmox VE 8.2（KVM/QEMU）
VMware vSphere 8.0 U2
共享儲存
Ceph（全 NVMe，10GbE 兩條聚合）
vSAN（全 NVMe，10GbE 兩條聚合）
備份伺服器
PBS 3.2，獨立實體機、ZFS RAID-Z1、NVMe 快取
備份網路
10GbE 專用網段
10GbE 專用網段
兩邊各部署 30 台虛擬機，其中 24 台為一般應用伺服器（Windows Server 2019/2022、Ubuntu 22.04），4 台為 SQL Server 2022（資料庫 500 GB），2 台為檔案伺服器（1 TB）。為避免快取造成的假象，每輪測試前皆重新開機並清空快取，且每個測試重複三次取中位數。
3.2 測試腳本與資料集
我們設計了三種變更量情境，模擬日常維運的真實樣貌：
變更量以虛擬磁碟大小為基準計算，並使用 fio 與自製 PowerShell 腳本產生可重現的寫入模式。所有時間量測皆採用「從備份工作啟動到工作結束」的牆鐘時間（wall-clock time），避免只計算資料傳輸時間而忽略快照建立、驗證等階段。
3.3 量測指標定義
我們記錄以下指標：
首次全備份時間：從零開始的第一次完整備份。
增量備份時間：每日例行增量備份的平均耗時。
吞吐量（MB/s）：實際處理的資料量除以時間。
完整還原時間：將虛擬機完整還原至新位置的耗時。
檔案級還原時間：從備份中取回單一檔案或資料夾的耗時。
即時還原啟動時間：從備份直接啟動服務、可對外提供連線的時間。
必須聲明：本測試為特定硬體與特定版本下的結果，實務效能會受網路、儲存、檔案系統、壓縮設定與資料內容影響甚鉅，請勿將數字視為絕對保證。
四、增量備份速度實測：PBS 主場優勢明顯
4.1 首次全備份基準
先看最基礎的全備份。我們以 100 GB 的 Windows Server VM 為樣本，並另外測試 500 GB 的 SQL Server VM。
樣本
PBS 首次全備份
Veeam 首次全備份
差異
Windows Server VM（100 GB）
約 21 分 40 秒
約 19 分 05 秒
Veeam 快約 12%
SQL Server VM（500 GB）
約 1 小時 46 分
約 1 小時 32 分
Veeam 快約 13%
檔案伺服器（1 TB）
約 3 小時 24 分
約 2 小時 51 分
Veeam 快約 16%
首次全備份 Veeam 略勝一籌，原因合理：vSphere 的資料讀取路徑已經過多年最佳化，而 ReFS 的 Block Cloning 在寫入階段也發揮了作用；PBS 這邊雖然 ZFS 寫入效率不錯，但每個區塊都要計算 SHA-256 雜湊、查表去重，額外的 CPU 負擔讓吞吐量略低。
值得一提的是，PBS 的去重效果在「同質 VM 多」的環境中會愈來愈明顯。我們的 30 台 VM 有 18 台是同一份 Windows Server 2022 樣板複製出來的，第二輪之後全備份的實際寫入量大幅下降，這是 PBS 架構上的先天優勢。
4.2 每日增量（3%～15% 變更量）
這才是真正的戰場。下表為完成首次全備份後，連續 10 天每日增量的中位數時間。
情境
VM 大小
PBS 增量時間
Veeam 增量時間
差異
A（3%～5% 變更）
100 GB
1 分 52 秒
2 分 35 秒
PBS 快約 28%
B（10%～15% 變更）
500 GB
5 分 08 秒
7 分 22 秒
PBS 快約 30%
B（10%～15% 變更）
1 TB
10 分 41 秒
14 分 55 秒
PBS 快約 28%
PBS 在增量情境中穩定領先約三成。原因有兩層：第一，PBS 的增量是「區塊級上傳 + 伺服器端去重」，客戶端只需傳送變更的 chunk，且不涉及備份鏈的合併；第二，Veeam 每次增量完成後，若採用 Forever Forward Incremental，仍需在背景進行合成式完整備份（雖然 ReFS Block Cloning 極快，但仍有中繼資料操作成本）。
另外，PBS 有一個很實用的特性：備份工作可以設定「驗證」與「垃圾回收」的獨立排程，避免它們與備份時間重疊。我們的測試中，若把 GC 排在備份窗口內，PBS 的增量時間會拉長到 8 分鐘以上，這點務必注意。
4.3 大規模變更（50% 以上）與資料庫情境
當變更量衝到 50%，兩者的差距開始縮小，因為此時瓶頸從「中繼資料處理」轉移到「實際資料搬移」。
情境
VM 大小
PBS 增量時間
Veeam 增量時間
差異
C（約 50% 變更）
500 GB
28 分 16 秒
26 分 48 秒
Veeam 快約 5%
SQL Server 交易記錄備份
500 GB
不支援原生交易記錄備份
約 3 分 10 秒（每 15 分鐘）
Veeam 具絕對優勢
這個結果很關鍵：PBS 的優勢建立在「小額變更、頻繁備份」的情境上。若你的環境常常有大量資料一次變動（例如每日批次匯入、影音素材上傳），PBS 的區塊去重幫不上太多忙，反而 Veeam 在應用程式感知與交易記錄層級的備份策略更有彈性。
特別提醒 SQL Server 使用者：PBS 目前沒有針對 Microsoft SQL Server 的原生 VSS 交易記錄備份功能，只能做映像級備份，資料庫的 RPO 會被壓縮到「備份排程間隔」。若你的資料庫容許的資料損失時間是 15 分鐘，那 PBS 在這個環節就必須搭配資料庫自身的日誌傳送或 Always On 來補足，不能單靠備份系統解決。
五、還原速度實測：Veeam 的還原花樣與 PBS 的樸實效率
5.1 完整還原（Full Restore）
完整還原測試中，我們將 VM 還原到全新的資料存放區，避免覆蓋原機造成快取污染。
樣本
PBS 完整還原
Veeam 完整還原
差異
Windows Server VM（100 GB）
約 9 分 30 秒
約 11 分 15 秒
PBS 快約 16%
SQL Server VM（500 GB）
約 48 分 20 秒
約 55 分 40 秒
PBS 快約 13%
檔案伺服器（1 TB）
約 1 小時 42 分
約 1 小時 58 分
PBS 快約 14%
有趣的是，PBS 在還原階段反而逆轉勝。主要原因有兩個：一是 PBS 的還原直接從 chunk store 讀取並依索引重組，不需要處理備份鏈；二是 ZFS 的讀取快取與 RAID 條帶配置在大量循序讀取時表現優異。Veeam 雖然在 vSphere 環境中有 Hot-Add 模式可加速，但完整還原仍需經過備份鏈解構與 VMDK 寫入，略有額外開銷。
5.2 檔案級還原與即時還原
這裡就是 Veeam 的主場了。我們測試了「從備份中取回單一資料夾（約 2 GB）」與「直接從備份啟動 VM」兩種情境。
還原形式
PBS
Veeam
檔案級還原（2 GB 資料夾）
約 1 分 05 秒（需先掛載或使用 PBS 的檔案瀏覽介面）
約 50 秒（File Level Restore 精靈，可跨平台瀏覽）
單一檔案還原（500 MB）
約 20 秒
約 15 秒
即時還原啟動
Live Restore 可邊還原邊啟動，100 GB VM 約 2 分 30 秒可開機
Instant Recovery，100 GB VM 約 1 分 40 秒可對外服務
PBS 的檔案級還原在 3.x 版本後已大幅改善，可以透過 PVE 介面直接瀏覽備份內容並取回檔案，但體驗仍不如 Veeam 的 File Level Restore 精靈來得直覺（尤其是跨 Linux/Windows 混合環境）。Veeam 的 Instant Recovery 更是經典功能：直接把備份檔案掛載成 NFS 或 SMB 分享，VM 從備份儲存執行，服務幾乎可以「秒開」，之後再排程遷回正式儲存。對於 RTO 要求嚴苛的場景，這是壓倒性的優勢。
PBS 的 Live Restore 雖然也有類似概念，但它本質上是「邊還原邊啟動」，仍需要把資料寫回目標儲存，只是順序上讓 VM 先開機。在 100 GB 以下的小型 VM 上差異不大，但對 TB 級 VM 就有明顯差別。
5.3 掛載驗證與顆粒化還原
備份如果沒驗證，等於沒備份。PBS 提供 verify 作業，可定期對備份區塊做雜湊比對，確認資料完整性；Veeam 則有 SureBackup，能自動把 VM 在隔離網路中啟動、執行腳本測試（例如檢查服務是否回應、資料庫是否可連線），測完自動關機。
在「顆粒化還原」這件事上，Veeam 支援 Active Directory 物件還原、Exchange 郵件還原、SQL Server 資料庫還原到特定時間點，這些都需要應用程式層級的整合。PBS 目前就是把 VM 當成一個整體，應用程式層的還原得靠 VM 內部工具處理。這不是 PBS 的缺陷，而是產品定位不同——它專注把「VM 映像備份」做到極致。
六、效能影響因素與調校建議
6.1 網路與儲存的瓶頸判斷
在我們的測試中，增量備份的瓶頸幾乎都在「來源端讀取 + 網路傳輸」，而還原的瓶頸則在「目標儲存寫入」。提供幾個實務判斷法：
6.2 壓縮、加密與去重的取捨
PBS 預設啟用 zstd 壓縮，對一般文字型資料效果不錯，但對已壓縮的資料（如 JPEG、影片、資料庫備份檔）幾乎無效。若你的環境大量存放這類資料，建議關閉壓縮以節省 CPU。加密方面，PBS 支援 AES-256 加密，對效能影響約 5%～10%；Veeam 同樣支援加密，且可與壓縮並行處理。
去重方面，PBS 是「全域去重」，Veeam 則可選擇「Per-VM」或「跨 VM」去重（需啟用 inline deduplication，對 CPU 負擔較大）。實務上，若 VM 數量多且同質性高，PBS 的全域去重帶來的儲存節省非常驚人；若 VM 內容差異大，Veeam 的彈性設定反而更適合。
6.3 排程設計：把驗證與 GC 移出備份窗口
這是我們測試中最容易踩到的坑。PBS 的 GC 與 verify 都會佔用磁碟 I/O，若與備份時段重疊，增量時間可能翻倍。建議做法：
備份窗口：凌晨 1:00～5:00。
驗證作業：每週日白天執行。
垃圾回收：每週一次，安排在驗證之後，並確認與備份排程至少間隔兩小時。
Veeam 這邊則要注意健康檢查（Health Check）與合成式完整備份的排程，避免在備份高峰期間觸發大量 I/O。若使用 ReFS，建議定期執行 ReFS 完整性掃描，並保留足夠的可用空間（建議至少 20%），否則 Block Cloning 效率會下降。
七、成本、維運與生態系的綜合比較
把效能放一邊，從維運角度來看，兩者的差異其實更明顯。
面向
Proxmox Backup Server
Veeam Backup & Replication
授權成本
開源免費，企業版訂閱可選
依 VM 數計價，功能分級
平台支援
Proxmox VE 原生，其他平台需透過代理或第三方
vSphere、Hyper-V、Nutanix AHV、Proxmox VE（12.2 起）、雲端
管理介面
Web 介面，與 PVE 深度整合
Windows 主控台，功能豐富但學習曲線較陡
應用程式感知
有限（映像級為主）
完整（VSS、SQL、Oracle、AD、Exchange）
即時還原
Live Restore（邊還原邊啟動）
Instant Recovery（直接從備份執行）
驗證機制
區塊雜湊驗證
SureBackup 自動化測試
除錯難度
日誌清楚，社群資源相對少
文件與社群龐大，企業支援成熟
從維運團隊的角度，PBS 的「單一介面搞定備份與還原」對小團隊非常友善，不需要額外維護 Windows 主機與授權伺服器。Veeam 則需要專責人員熟悉其備份鏈、Repository 與各項進階功能，但換來的是更完整的企業級能力與技術支援。
八、結論與選型建議
經過六週實測，我們的結論如下：
如果你是純 Proxmox VE 環境、VM 數量多、變更量以日常小幅異動為主，而且團隊規模小、預算有限，PBS 幾乎是無懸念的選擇。它的增量備份速度快、去重效率高、還原速度穩定，維運成本極低。唯一要特別注意的是應用程式層級的備份需求，以及 GC／驗證排程的規劃。
如果你身處 vSphere 或混合雲環境、需要應用程式感知備份、要求極短的 RTO、或需要跨平台遷移能力，Veeam 的功能深度與成熟度仍是首選。它的增量速度雖略遜於 PBS，但在「還原的多樣性」與「自動化驗證」上，價值遠超過那幾分鐘的差距。
至於「兩者能不能並存」？實務上，已有不少團隊在 Proxmox VE 上用 PBS 做第一線備份，再將 PBS 的資料同步到異地或雲端；若環境同時有 vSphere，則以 Veeam 保護 vSphere、PBS 保護 PVE，各自發揮所長。備份架構沒有標準答案，只有最貼近你 RPO／RTO 與預算的答案。
最後提醒，本文數據來自特定硬體與版本，實際效能會因環境而異。建議讀者在正式導入前，先用自身環境進行為期一至兩週的 PoC，特別是增量備份的「變更量分布」與「儲存 I/O 特性」，這兩項往往比規格表上的數字更能決定成敗。若你有不同的實測結果，歡迎在雅寶社區 · 頂客論壇的軟體評測版分享，讓更多維運夥伴少走冤枉路。
※ 本文測試數據僅供參考，不構成任何採購或架構決策之保證。各產品版本與功能請以官方文件為準。
```
💬 想說點什麼？
歡迎到留言板分享你的想法、心得或疑問。
💬 前往留言板 →