實作去重壓縮的伺服器端備份

資料去重只會將重複的資料片段儲存一次，而壓縮則會進一步縮小剩餘唯一資料的體積。這兩種技術之所以對伺服器端備份至關重要，是因為它們能夠降低資料儲存成本、縮短備份視窗，並支援更長的保留週期。本文聚焦於伺服器端（亦即目標端）去重。你將了解分塊、雜湊、流程管線設計以及正式環境調校如何協同運作。本文目標是協助你建構一條可落地的處理流程管線，並提供切實可行的效能與可靠性指引。去重會先於壓縮執行，以先減少資料占用。這個順序對效率至關重要。經過良好調校的去重流程管線，能夠顯著降低資料儲存需求，並縮短備份時間。你也將學會如何監控去重效果，並避開常見陷阱。

資料去重與壓縮基礎

要實現高效儲存，你需要掌握兩項核心技術。資料去重會僅保留每個唯一資料區塊的一份副本；壓縮則進一步縮小這些唯一資料區塊的體積。應先執行前者，再執行後者。這樣的順序能最大化節省空間，避免將重複內容重複儲存。

Windows Server 資料重複刪除功能可以最佳化任何磁碟區上的可用空間。你可以安裝該功能，並依照需求設定自訂排程。此功能能夠良好處理多種伺服器工作負載，包括檔案伺服器與備份目標。

來源端去重與目標端去重

處理位置的不同會改變你的整體工作流程。來源端處理會在資料穿越網路之前先移除重複區塊，從而減少頻寬占用，而且無需額外硬體。目標端處理則是在完整資料流到達儲存裝置之後再進行處理，這種方式會將工作負載轉移到備份目標端。

你的網路基礎架構會影響這項選擇。目標端處理適合具備高速網路與專用設備的環境；而當頻寬有限時，來源端處理會更為合適。在做決定之前，請先明確你的備份去重策略。正確的選擇取決於你的具體環境。

即時去重與後處理去重

處理時機同樣會影響系統效能。即時處理會在資料到達目標端時立即進行；後處理則會先完整儲存備份資料，再於後續階段消除冗餘。兩種方式各有優勢。

當你需要保持效能穩定，同時又不確定容量最佳化會帶來多大影響時，後處理通常是更佳的選擇。由於最佳化發生在資料寫入之後，因此在寫入階段幾乎不會帶來效能影響。

下表展示了兩種方法在吞吐量上的差異：

備份視窗大小決定了哪種方式更適合你。即時方式能夠立即節省儲存空間，但可能拖慢處理速度；後處理能更快完成備份，但會暫時占用更多磁碟空間。理解壓縮與去重的處理時機，有助於你設計更優的系統。

用於備份的分塊與雜湊

分塊會先將資料流拆分為更小的片段，隨後去重系統才能對這些片段進行比較。雜湊則會為每個片段產生一個簡短的「指紋」。這兩個步驟共同決定了你的備份流程管線能否高效發現並消除冗餘。

固定長度分塊與可變長度分塊

固定長度分塊會把資料流切分成大小一致的資料區塊。你只需設定區塊大小，之後每個分塊都保持一致。這種方法簡單、可預測，而且處理速度快，因為系統無需搜尋邊界。其弱點在於資料一旦發生位移，效果就會變差。比如在檔案開頭附近插入一個位元組，後續所有區塊邊界都會隨之移動。雖然內容本身幾乎未變，但雜湊指紋會全部改變。結果就是，本該跳過的重複資料也會被重新儲存。

可變長度分塊則依據內容而非位置來決定邊界。系統會掃描資料流，在偵測到某種模式時進行切分。這樣，微小修改通常只會影響包含該修改的那個分塊，其他分塊仍能保持原有邊界與雜湊值。這種方式在處理發生位移的資料時能獲得更高的去重率，尤其適用於資料庫與虛擬機映像。代價是每個位元組需要更多運算。選擇哪種方式取決於你的資料特性。穩定的封存資料適合固定區塊；頻繁變動的檔案則更適合可變區塊。

雜湊演算法與碰撞

雜湊函式會將每個分塊轉換為一個固定長度的值。SHA-256 是常見選擇，研究充分、應用廣泛且值得信賴。BLAKE3 在現代硬體上執行更快，更適合高吞吐量流程管線。這兩種演算法都能產生足夠長的值，因此意外碰撞極為罕見。

所謂碰撞，是指兩個不同分塊得到了相同的雜湊值。你不能僅憑雜湊相同就認定內容一致。安全的做法是執行位元組級驗證。當索引回報命中時，將新分塊與已儲存分塊逐位元組比較；只有在位元組內容確實不同的情況下，才儲存新分塊。這個檢查會增加一次讀取開銷，但能防止靜默資料損毀。許多正式環境系統為了追求速度而跳過驗證，並接受相應風險。對於備份資料而言，驗證成本是值得承擔的。

建構伺服器端備份流程管線

建構伺服器端備份流程管線需要精心設計。其工作流程本質上並不複雜，但每一步都必須能夠高效處理大規模內容。你需要理解分塊、雜湊與索引查找如何彼此配合。一個具體的程式碼範例將幫助你更直觀地掌握這一過程。

流程管線工作流程

流程管線從備份來源送來的位元組流開始。系統讀取該資料流並將其拆分為多個分塊；隨後為每個分塊計算加密雜湊指紋；接著將該雜湊與去重索引進行比對。若命中，則表示該分塊已存在，可以跳過儲存；若未命中，則表示該分塊是唯一的，需要寫入儲存池。最後一步是寫入資訊清單（manifest），用於將原始檔案映射回其對應的唯一分塊。

分塊大小會直接影響整體效率。更小的分塊通常能帶來更高的去重率，因為資料變動往往不會覆蓋整個分塊，檔案中的位移也通常只會影響包含改動的那一塊。但與此同時，每個小分塊都需要額外中繼資料，包括雜湊、長度與位置等資訊。當分塊小到 256 位元組 時，雜湊與管理中繼資料就會在儲存中占據顯著比例，開銷不容忽視。更大的分塊能夠減少這類開銷，但會降低粒度，從而錯失在更小範圍內識別重複內容的機會。最佳設定取決於你的工作負載，平均檔案大小與變更率都很關鍵。像 SeqCDC 這樣的演算法在 8 KB 到 16 KB 的較大分塊範圍內，吞吐量可提升 15 倍。這種去重取捨會直接影響你的流程管線設計。

索引查找還面臨另一項挑戰：正式環境伺服器可能包含數十億個唯一分塊，你不可能將整個索引都放入記憶體。一種做法是讓雜湊僅用於定位而非身分確認。每個分塊先產生一個 128 位元的 BLAKE2b 指紋，再用其中一個位元組決定分片。該指紋本身無需寫入磁碟，這樣可以將工作集控制在可管理範圍內。真正的等值判斷仍然依賴完整的規範化內容，並在必要時執行逐位元組比對。透過這種設計，索引可以持續擴展，而無需讓記憶體占用按相同比例成長。

這裡也適用若干最佳實務。首先，分析你的資料，以評估其去重潛力；其次，在具代表性的資料集上進行測試，衡量去重率、寫入吞吐量與索引成長；然後，根據效能需求選擇即時或後處理去重；同時確保有足夠的處理器效能與記憶體資源。索引一旦得不到足夠資源支撐，效能就會急劇下滑。還要持續監控並按需調整。應將中繼資料視為關鍵資料庫來管理，並為其設定還原點。

Veeam Backup & Replication 提供了資料去重與壓縮機制，可減少備份檔案與虛擬機複本檔案的網路流量與磁碟空間占用。Veeam 能夠識別同一虛擬機磁碟內部的重複區塊，也能識別同一作業中多個虛擬機之間的重複區塊。這在虛擬機由同一範本部署時尤其有幫助。對於典型虛擬機工作負載，其去重比通常在 10:1 到 50:1 之間。

程式碼範例：分塊、雜湊、索引

下面的 Python 程式碼片段展示了流程管線的核心步驟。它會讀取檔案，將檔案按固定大小分塊，使用 SHA-256 對每個資料區塊進行雜湊，並檢查索引是否已存在。

import hashlib

CHUNK_SIZE = 65536  # 64 KB
index = {}  # 雜湊 -> 儲存位置

def process_backup(file_path):
    with open(file_path, 'rb') as f:
        chunk_num = 0
        while True:
            data = f.read(CHUNK_SIZE)
            if not data:
                break
            h = hashlib.sha256(data).hexdigest()
            if h in index:
                print(f"資料區塊 {chunk_num} 重複，跳過")
            else:
                loc = write_chunk(data)
                index[h] = loc
                print(f"資料區塊 {chunk_num} 為新區塊，已儲存")
            chunk_num += 1

這個範例為了簡潔起見使用了固定長度分塊。正式環境系統通常會採用可變長度分塊與持久化索引。雜湊檢查發生在任何寫入操作之前，因此能夠避免儲存已經存在的內容。write_chunk 函式負責儲存資料內容，並回傳其儲存位置。索引會在多次備份作業之間持續保留。

備份去重效能與正式環境實務

正式環境系統需要的不只是「能跑起來」的流程管線。你還需要調校效能、管理規模，並為長期可靠性做好規劃。你在這些方面所做的選擇，將決定備份視窗能否保持足夠短，儲存成本能否維持在可控範圍內。

索引快取、Bloom 過濾器與平行處理

去重索引是整個系統的效能瓶頸。決定去重效能的往往不是 CPU，而是中繼資料存取延遲。應將去重表放在鏡像 NVMe 或 Optane 儲存上，並使用去重配額來避免當表溢位到較慢裝置時出現效能斷崖。雜湊計算本身在現代系統中已不再是主要難題。現代 CPU 普遍支援 SHA-NI 硬體加速，使得區塊雜湊相對於流程管線其他環節而言開銷很低。

Bloom 過濾器可以幫助你跳過不必要的索引查找。它是一種緊湊的機率型資料結構，可以告訴你某個分塊「可能存在」還是「一定不存在」於索引中。如果結果為否，則該分塊必然是新的，可以直接寫入而無需存取索引；如果結果為是，則再去檢查完整索引。對於大量唯一資料，這種方法能顯著減少索引讀取次數。

平行處理能夠提升吞吐量，但也伴隨著取捨。應用於 band processing 和 candidate intersection 的 SIMD 加速可以提高去重速度，但這種以批次為基礎的方法僅在批次相對於語料庫規模較小時效果理想。另一方面，MinHash 簽章的 Jaccard 相似度難以透過平行化技術有效加速，還可能導致簽章擁擠（signature crowding）問題。分區鎖定（zone-based locking）則提供了另一條路徑。每個分區對自身結構擁有隱含鎖，從而保證其他執行緒不會修改它們。不過，每次 VDO 目標啟動時，都需要重新設定分區數量與執行緒數量。

高強度去重會導致區塊碎片化。順序讀取會逐漸表現得更像隨機 I/O，從而增加讀取延遲。快取與智慧配置策略可以緩解這一影響。虛擬機與資料庫這類隨機存取工作負載受影響較小，而媒體串流與大檔案傳輸等順序型工作負載受影響更明顯。下表總結了在正式環境中啟用去重後的效能影響。

全域去重與本地去重、垃圾回收、壓縮順序

全域去重會在整個資料集範圍內，跨所有節點與磁碟裝置查找並移除重複資料；本地去重則僅限於單一節點或單一磁碟裝置。去重涵蓋的資料範圍越大，效果通常越好。因此，在多節點環境中，如果每個節點都只執行本地去重，其效率通常低於整個叢集範圍的全域去重。Cohesity 指出，跨叢集所有節點的全域去重，相較若干其他備份與還原方案所採用的節點級去重，能夠占用更少的儲存空間。

對於正式環境等級的備份去重而言，可擴充性同樣關鍵。ExaGrid 採用 GRID 架構，透過隨著資料成長增加完整伺服器來擴充能力。這種方式會同步增加記憶體、處理器、磁碟與頻寬資源。而一些競爭對手採用前端伺服器架構，只能透過增加磁碟櫃來擴充，最終會導致備份視窗不斷拉長，直到不得不進行成本高昂的整機替換升級。ExaGrid 的 GRID 方法能夠隨著資料成長維持固定長度的備份視窗，無需整機替換，也不會導致產品過時。ExaGrid 的分區級去重（zone-level deduplication）曾幫助 Concur 以 177 TB 磁碟空間儲存近 3 PB 資料，展現了透過模組化容量成長與隨需擴充所實現的高性價比可擴充性。

垃圾回收（GC）用於回收孤立分塊。當你刪除某個備份，或某個分塊不再被任何物件引用時，這部分空間並不會立刻釋放，只有在 GC 執行後才會真正回收。如果垃圾回收成功刪除未使用分塊，區塊儲存的占用就會減少，磁碟區上的可用空間也會增加。完整垃圾回收開銷較大，通常以週期性工作執行。當發生了大量刪除操作但空間仍未回收時，手動執行完整 GC 是合理的。在 Windows Server 中，去重過程中由完整 GC 引起的抖動可能帶來效能問題。

垃圾回收與去重之間存在複雜互動。GC 有助於降低碎片，但如果某個原本「死亡」的區域中還保留了哪怕一個存活分塊，區域級清理就無法釋放整個區域。也就是說，去重引發的碎片化會阻礙回收。若僅依據指紋去重而缺乏時間區域性，檔案資料就可能分散到大量資料區塊中，從而拖慢讀取與還原效能。啟用字串去重後，垃圾回收器的停頓時間也會更長。更高的 CPU 使用率，則是啟用去重時垃圾回收週期中的主要代價。

壓縮應在去重之後執行。即時去重完成後，可將壓縮作為可選步驟進一步縮小已去重資料區塊的大小。這樣的順序能夠最大化整體儲存效率。下表展示了「去重後再壓縮」與「不執行該順序」之間的資料縮減比差異。

該表說明，當關閉備份軟體自身壓縮、轉而讓 VAST 對去重後的資料執行自身壓縮時，縮減比可從 6:1 提升到 22:1。這進一步證明：先去重後壓縮，能夠帶來顯著額外收益。

加密相容性同樣值得關注。只要共用相同的加密情境，ZFS 原生加密仍可與去重相容。而上游應用層加密會將資料區塊隨機化，使去重比接近 1:1。你的加密策略應與去重目標協同規劃。

在備份中實作去重，能夠降低儲存成本並縮短備份視窗。本節介紹的這些技術，能夠幫助你在正式環境規模下實現這些目標。建議先從試點資料集開始，衡量結果後再反覆優化，最後再推廣到更大規模。

監控壓縮與去重效果

無法量測，就無法調校。對每個備份作業，你都應追蹤四項指標：去重比、壓縮比、吞吐量，以及索引命中率。去重比反映流程管線移除了多少冗餘資料；壓縮比反映剩餘唯一資料區塊被縮小了多少；吞吐量決定備份視窗是否仍在可接受範圍內；索引命中率則顯示查找既有分塊的成功頻率。若命中率持續下降，通常意味著資料發生了位移，或分塊策略出現問題。不要只看單次結果，而應持續觀察這些指標的趨勢。

量測去重比與吞吐量

去重比的計算方式是：邏輯位元組數除以實際儲存位元組數。例如 10:1 表示你只儲存了原始資料量的十分之一。吞吐量應在寫入入口處以 MB/s 進行量測，而不是直接在磁碟層量測，這樣能夠將流程管線本身的代價與儲存延遲區分開來。應按作業與資料集分別取樣這兩項指標，單一的彙總數字往往會掩蓋某一類工作負載中的問題。將結果與試點階段建立的基準進行比較。如果吞吐量下降而去重比保持穩定，那麼瓶頸通常位於索引或中繼資料層。

你的最終流程管線應具備清晰的處理流程：先對資料流進行分塊，再為每一塊計算雜湊，接著檢查索引，只儲存唯一資料，最後再對這些分塊執行壓縮。影響設計的關鍵取捨包括：

• 即時去重能夠節省儲存，但會拖慢資料寫入；後處理寫入更快，並在之後再進行去重，不影響寫入速度。

• 固定分塊實作簡單；可變分塊更能適應發生位移的資料，從而獲得更高的去重率。

• 全域去重涵蓋所有節點，能帶來更高的資料縮減率；本地去重範圍較小，但索引開銷也更低。

可先在試點資料集上測試 Windows Server 資料重複刪除與 Veeam Backup & Replication，量測備份縮減比與吞吐量，並在全面部署伺服器備份之前持續反覆優化。這樣才能讓備份去重真正適用於你的備份資料。

常見問題

即時去重和後處理去重有什麼區別？

即時去重會在資料到達時立即處理，能夠立刻節省儲存空間，但可能降低寫入速度。後處理去重則會先將完整備份寫入伺服器，再於後續階段移除冗餘。這樣可以保持較高的備份速度，但會暫時額外占用磁碟空間。

為什麼可變長度分塊能改善去重效果？

可變長度分塊根據內容模式而非固定位置來決定邊界。一次小改動通常只會影響包含該改動的那個分塊，其他分塊仍能保留原有邊界與雜湊值。因此，這種方式在處理發生位移的資料時，通常能獲得更好的去重效果。

為什麼壓縮應該在去重之後執行？

對唯一資料區塊在去重後再執行壓縮，能夠最大化儲存效率。每個唯一資料區塊都可以被個別壓縮，而不會把算力浪費在最終會被丟棄的重複資料上。這個順序能夠避免無效壓縮，並直接影響整體縮減比。

應追蹤哪些去重效能指標？

對每個伺服器作業，應追蹤四項關鍵指標：去重比、壓縮比、吞吐量與索引命中率。去重比顯示流程管線移除了多少冗餘資料；吞吐量反映備份視窗是否仍然可接受。建議按作業分別監控這些指標。

加密會如何影響去重效果？

加密會使資料呈現隨機化特徵，從而讓原本相同的資料區塊看起來彼此不同。應用層加密會破壞去重效果，因為即使來自相同來源資料，加密後的密文通常也會表現為唯一內容。為了避免失去儲存節省效果，你需要圍繞備份資料妥善規劃加密策略。