伺服器端備份：資料去重與壓縮

本教學將向你展示如何在伺服器端備份中執行資料去重與壓縮。你的目標很明確：降低儲存成本，並讓每一次備份作業更快、更高效。資料保護團隊每年都在面對不斷成長的資料量。這兩項技術能夠在保留每一個還原點完整性的同時，減少需要儲存的位元組數。去重會移除重複的資料區塊，壓縮則會將剩餘資料壓得更緊。這兩項功能都執行於伺服器端，因此你現有的作業流程無須改變。實施過程強調實作。你需要針對真實工作負載完成設定、驗證與調校。這種方式能避免正式環境遭遇意外。務必先在實驗環境中完成所有測試。

去重與壓縮對資料保護的價值

去重與壓縮能夠減少備份資料的儲存占用，進而讓你的資料保護策略更高效、更具成本效益。在維持每個還原點完整的同時，你可以儲存更少的資料量。你也可以獲得更快的備份作業速度與更低的儲存成本。

去重如何減少備份儲存

去重會在你的備份檔案中尋找並移除重複的資料區塊。它使用基於雜湊索引的區塊層級去重，將每個資料區塊與雜湊索引進行比對。如果某個資料區塊已存在，系統就只儲存一個參照，而不是完整的資料區塊。這種方式對檔案伺服器尤其有效。檔案伺服器通常保存文件、圖片等非結構化資料。這類應用通常不會對自身資料進行壓縮，因此去重在這裡可以節省大量備份空間。透過使用基於雜湊索引的區塊層級去重，你可以在不額外增加 CPU 負載的前提下獲得顯著的儲存效益。

壓縮如何縮小備份資料體積

壓縮會進一步縮小剩餘唯一資料的體積。其效果會因資料類型而異：

• 資料庫備份檔案由於包含大量重複資料，可實現高達 20:1 的壓縮比。這種資料去重與壓縮可將整體備份儲存空間減少 95%（或相較於傳統方法減少 75%）。
• 圖片、音訊、影片和大型文件等非結構化資料，可優化的壓縮空間有限。

將去重與壓縮結合使用，能夠帶來最佳效果。你不僅可以降低儲存成本，還能提升備份與復原效能。這也有助於達成你的災難復原目標。更高的儲存效率意味著你可以在現有資源上保留更多復原點。資料體積越小，整體儲存支出也越低。

資料去重與壓縮如何協同運作

將資料去重與壓縮結合使用，可以帶來額外的儲存節省。你先執行基於雜湊索引的區塊層級去重以移除重複區塊，然後再對剩餘的唯一資料套用壓縮。這個兩步驟流程有助於實現你的資料保護與災難復原目標。你可以在相同的硬體上保留更多復原點，同時降低整體儲存成本。它會強制使用固定的壓縮區塊大小，而這可能限制壓縮效率。Veeam 僅在單一備份檔案內執行去重。將更多伺服器放入同一個檔案，會提升整體效果。MSDP 技術可實現雲端去重、壓縮與加密，從而縮短處理時間並加快復原速度。

去重層級與類型

去重主要分為兩個層級：來源端去重和目標端去重。來源端去重在資料傳輸到目標之前，於伺服器端執行。目標端去重則在資料到達儲存裝置後再進行處理。你的選擇取決於工作負載與基礎架構。至於去重類型，則需要在固定長度區塊去重與可變長度區塊去重之間做選擇。可變長度去重能夠解決一個稱為 chunk shift 的問題。下表對這兩種方式進行了比較：

基於內容的即時去重使用的是內容定義分塊（content-defined chunking）方法。該方法根據滿足預設條件的位元組來設定區塊邊界。

研究表明，與固定大小分塊相比，它能偵測出更多冗餘資料，從而支援更高的縮減率。

壓縮演算法與區塊大小

完成去重後，接下來就要套用壓縮。基於雜湊索引的區塊層級去重會為你的檔案定義區塊大小。這個固定區塊大小會成為壓縮的基本單位。較大的區塊可提升壓縮比，但會占用更多記憶體。較小的區塊會減少 CPU 消耗，但資料縮減效果也較弱。你必須針對每類工作負載在這些取捨之間取得平衡。資料庫備份檔案通常適合較大的區塊。非結構化資料則可能更適合較小的區塊。在正式部署到正式環境之前，務必先在實驗環境中測試不同的區塊大小。持續監控 CPU、記憶體和復原時間。這樣的調校能確保你在不影響復原效能的前提下，獲得最佳的資料縮減效果。基於雜湊索引的區塊層級去重搭配合適的壓縮演算法，有助於實現你的儲存節省目標。

逐步實施資料去重

現在你已經了解了去重與壓縮如何協同運作。本節將帶你完成實際設定。你將選擇去重層級、對伺服器進行分組，並驗證第一次執行效果。

選擇合適的去重層級

你的第一個決策是選擇來源端去重還是目標端去重。兩種方式會把負載轉移到不同的位置。下表展示了它們之間的權衡：

如果網路鏈路是瓶頸，就選擇來源端去重。伺服器會在資料離開主機前先行處理，因此跨網路傳輸的資料更少，但正式環境 CPU 會承擔額外工作。如果你的正式環境伺服器本身負載已經很高，就選擇目標端去重。此時處理負載會轉移到備份伺服器上，但你需要充足的網路頻寬來支撐這種方案。

設定並執行去重

把多台伺服器歸入同一個備份檔案，可以顯著提升節省效果。Veeam 僅在單一備份檔案內執行去重。向該檔案中加入更多伺服器，去重引擎就能在它們之間發現更多重複區塊。例如，檔案伺服器和資料庫伺服器可能共享作業系統檔案，這些共享區塊只需去重一次。因此，你需要圍繞這一原則來規劃作業配置。

依照以下步驟設定並驗證你的首次執行：

1. 建立一個新的備份作業，並加入你希望分組的伺服器。
2. 在作業設定中啟用基於雜湊索引的區塊層級去重。
3. 根據上表選擇合適的去重層級。
4. 執行作業，並等待首次完整備份完成。
5. 檢查作業報告中的去重比率。
6. 將儲存後的大小與來源資料大小進行比較。

基於雜湊索引的區塊層級去重會在首次執行時建立雜湊索引。後續執行時，新資料區塊會與該索引進行比對。較高的比率表示你的分組策略效果良好；較低的比率則意味著你可能需要將更多相似伺服器加入同一個作業。你也可以檢查正式環境伺服器與備份伺服器上的 CPU 與記憶體使用情況，並留意是否出現會影響工作時段的資源高峰。

在擴大部署之前，驗證至關重要。請從去重後的備份中執行一次測試復原，確認每一個檔案都能完整復原。這一步能夠及早發現設定錯誤。復原測試成功後，你就可以將作業擴展到更多伺服器。基於雜湊索引的區塊層級去重透過周密規劃，往往能帶來可觀的儲存節省。

逐步實施壓縮

套用並調校壓縮

選定壓縮演算法後，就需要在作業設定中啟用壓縮。相關步驟與去重設定類似。你需要設定壓縮等級並選擇區塊大小。

依照以下步驟套用壓縮：

1. 開啟你的作業並進入儲存設定。
2. 從清單中選擇你所需的壓縮演算法。
3. 選擇初始壓縮等級。若使用 Zstandard，建議從 level 3 開始。
4. 設定區塊大小。較大的區塊有助於進一步縮小檔案整體體積，但會占用更多記憶體；較小的區塊會降低 CPU 負載，但縮減效果較弱。
5. 執行測試作業，並查看作業報告中的壓縮比率。
6. 將壓縮後的大小與未壓縮大小進行比較。

調校需要反覆迭代。使用不同的區塊大小與壓縮等級進行多輪測試。監控作業時段內的 CPU 使用率。過高的 CPU 占用可能會拖慢其他正式環境任務。檢查壓縮比是否符合你的預期，同時也要監控復原時間。高度壓縮的檔案在復原時可能需要更長時間進行解壓縮，而災難復原情境往往要求快速復原。還要檢查記憶體消耗，因為較大的區塊大小會在壓縮與解壓縮期間都占用更多 RAM。

請先在具有代表性的資料樣本上測試壓縮效果。真實工作負載的模式與合成基準測試往往不同。適用於資料庫備份的方法，不一定適用於檔案伺服器。

資料庫檔案通常更適合較大的區塊，而圖片、影片等非結構化資料可能更適合較小的區塊。請分別測試每一種工作負載類型。最佳平衡點取決於你的基礎架構條件。完成調校後，再執行一次完整復原測試，確認所有檔案都能正確復原。

至此，壓縮的實施完成了你的儲存縮減策略。將其與資料去重結合使用，通常能夠取得最佳效果。你會對檔案進行兩次「瘦身」：先移除重複資料區塊，再將剩餘資料壓得更緊。這樣既能顯著節省儲存空間，也能維持備份復原流程的快速與可靠。

降低備份儲存的最佳實務

最佳化效能與節省效果

在接觸正式環境之前，先在展示環境或實驗環境中測試去重與壓縮。實驗環境能讓你根據真實工作負載測量實際比率。合成基準測試往往具有誤導性。請先跑完整個備份週期，然後再執行復原測試。這一步可以確保你的設定在影響真實資料之前已被驗證無誤。

將相似的伺服器分組到同一個備份檔案中。基於雜湊索引的區塊層級去重會在更多伺服器共用同一作業時，發現更多重複區塊。例如，檔案伺服器與資料庫伺服器可能共享作業系統檔案，這些共享區塊只需要去重一次。這種方式能夠提升整體環境的儲存效率。

避免資料完整性問題

在啟用這兩項功能後，持續監控 CPU、記憶體與復原時間。備份時段內過高的 CPU 使用率可能拖慢正式環境任務。較大的壓縮區塊在壓縮與解壓縮時都需要更多 RAM。請留意是否出現影響工作時段的資源高峰。

定期檢查復原時間。高度壓縮的檔案在復原過程中可能需要更長時間解壓縮，而災難復原要求你具備快速復原能力。每次變更設定後都要執行一次測試復原，並確認每個檔案都能完整復原。

基於雜湊索引的區塊層級去重非常依賴周密規劃。降低儲存占用有助於實現你的資料保護目標，縮短復原時間則有助於支撐你的災難復原計畫。而這兩項成果都依賴於持續監控與定期測試。只有驗證每一次變更，你的備份與復原策略才能保持可靠。

現在，你已經掌握了一條清晰的伺服器端去重與壓縮實施路徑。先將相似伺服器歸入同一個備份檔案，選擇來源端或目標端去重，再選用如 Zstandard 這樣的壓縮演算法。透過測試復原來驗證每一項變更。這些步驟將幫助你縮小儲存占用、加快作業速度並降低成本。

務必先在展示環境或實驗環境中完成所有測試。測量真實比率、觀察 CPU 與記憶體，並確認復原速度足夠快。強而有力的資料保護與災難復原能力，正是建立在這種嚴謹實務之上。下載我們的檢查清單，立即開始降低你的儲存成本。

常見問題

應該選擇哪一種去重層級？

當網路鏈路是瓶頸時，選擇來源端去重。伺服器會在資料離開主機前先行處理，因此跨網路傳輸的資料更少。當正式環境伺服器本身負載較高時，選擇目標端去重。此時處理負載將由備份伺服器承擔。

為什麼把伺服器分組到同一個作業中很重要？

Veeam 僅在單一備份檔案內執行去重。向同一個檔案中加入更多伺服器後，引擎就能在它們之間發現更多重複區塊。例如，檔案伺服器和資料庫伺服器可能共享作業系統檔案，這些共享區塊只需去重一次，從而提升你的儲存節省效果。

哪一種壓縮演算法最適合備份？

Zstandard 對大多數作業而言提供了最佳平衡。它在維持與 zlib 相當壓縮率的同時，壓縮速度可快 3 到 5 倍。LZ4 則提供最高吞吐量與最低 CPU 負載。如果速度比降低總儲存量更重要，就選擇 LZ4。資料庫檔案尤其適合使用 Zstandard 壓縮。

已經壓縮過的資料還能啟用去重嗎？

不能。去重引擎無法在壓縮資料流內部識別重複區塊。當系統無法重建原始檔案時，復原過程可能失敗。應將去重用於那些不會自行壓縮資料的來源，例如檔案伺服器。

如何驗證新的設定？

在展示環境或實驗環境中執行一個完整的備份週期，然後從中執行復原。查看作業報告中的去重與壓縮比率，監控 CPU、記憶體與復原時間。在將作業擴展到更多伺服器之前，先確認每一個檔案都能完整復原。