我們認(rèn)為可變分塊技術(shù)，也就是說根據(jù)數(shù)據(jù)的內(nèi)容來分配塊的邊界，是相當(dāng)好的技術(shù)。不過，隨著重復(fù)數(shù)據(jù)刪除不局限于備份設(shè)備(比如磁帶，或其他備份應(yīng)用程序?qū)Ｓ酶袷降臄?shù)據(jù))，進(jìn)入備份應(yīng)用程序和主存儲，固定分塊重復(fù)數(shù)據(jù)刪除的優(yōu)勢開始變得明顯。
固定分塊重復(fù)數(shù)據(jù)刪除的主要優(yōu)勢在于占用較少的CPU資源。固定分塊系統(tǒng)不需要CPU開銷來檢查數(shù)據(jù)并判斷數(shù)據(jù)塊的邊界。它們只要將數(shù)據(jù)分解成數(shù)據(jù)塊，就像其他文件系統(tǒng)那樣。實際上，一些主存儲重復(fù)數(shù)據(jù)刪除，比如NetApp的產(chǎn)品，使用的正是底層文件系統(tǒng)的塊。
較低的開銷同時還意味著較低的延遲性。數(shù)據(jù)塊邊界的計算過程需要一些時間。雖然廠商們已經(jīng)在盡量減少這個時間并聲稱這種時間開銷是可以忽略的，但是這個過程和時間確實存在，對于主存儲重復(fù)數(shù)據(jù)刪除系統(tǒng)來說可能是個問題。
不過，對于備份應(yīng)用程序來說，這問題要簡單許多。備份應(yīng)用程序只是將數(shù)據(jù)流發(fā)送給某處的一個磁帶驅(qū)動器。由于它們只是向少數(shù)大型文件執(zhí)行大型順序?qū)懭胝埱?，因此每個請求發(fā)生數(shù)毫秒的延遲對于它們來說還不會有什么大的影響。對于傳統(tǒng)備份應(yīng)用程序，比如NetBackup或Networker來說，吞吐量才是最重要的，延遲性的重要性低一些。
主存儲應(yīng)用程序，即使是簡單的應(yīng)用程序，比如托管用戶的主目錄，對延遲性也非常敏感。此外，主存儲應(yīng)用環(huán)境不是像備份應(yīng)用程序那樣將數(shù)據(jù)寫入到少數(shù)大型文件，而是有數(shù)百萬個各種大小的文件。由于每個文件都從一個新的數(shù)據(jù)塊開始，因此數(shù)據(jù)插入或其他有可能帶來塊重整的修改只影響一個文件的數(shù)據(jù)。每個新文件都會重新調(diào)整流程。
基于軟件的重復(fù)數(shù)據(jù)刪除軟件--尤其是那些在源服務(wù)器端進(jìn)行重復(fù)數(shù)據(jù)刪除操作的應(yīng)用程序，比如Avamar、PureDisk或Asigra的Cloud Backup--也會使用文件開頭和結(jié)尾來判斷它們的塊邊界。這些應(yīng)用程序首先判斷哪些文件已經(jīng)發(fā)生修改，比如傳統(tǒng)的增量型備份，然后開始在每個文件上進(jìn)行分塊操作。
如果備份目標(biāo)端的重復(fù)數(shù)據(jù)刪除引擎知道磁帶的格式或?qū)arball這樣的文件(也就是你的備份應(yīng)用程序?qū)懭霐?shù)據(jù)的文件)整合在一起，那么使用文件邊界可以優(yōu)化備份目標(biāo)端的固定塊分塊流程。重復(fù)數(shù)據(jù)刪除引擎可以在Tarball內(nèi)判斷每個文件的開頭和結(jié)尾，并根據(jù)這些邊界對數(shù)據(jù)塊進(jìn)行重新調(diào)整。內(nèi)容感知功能同時也可以讓備份設(shè)備看到索引標(biāo)志，并為備份應(yīng)用程序插入到Tarball的數(shù)據(jù)編寫目錄以防止它們遭到分塊。
不過，固定塊系統(tǒng)可能在某些數(shù)據(jù)上會水土不服。我知道一位Data Domain用戶使用Exchange備份來測試賽門鐵克的PureDisk重復(fù)數(shù)據(jù)刪除。他們當(dāng)時在Data Domain上根據(jù)給定容量的存儲保存40個Exchange服務(wù)器備份，但是他們無法在同樣的存儲容量下保存4個被PureDisk執(zhí)行重復(fù)數(shù)據(jù)刪除的Exchange備份數(shù)據(jù)。Exchange數(shù)據(jù)是由小量大型數(shù)據(jù)庫文件組成的，而這些文件會在備份之間發(fā)生內(nèi)部改變。對于PureDisk的重復(fù)數(shù)據(jù)刪除引擎來說，這是最糟糕的情況?，F(xiàn)在，如果你使用固定塊重復(fù)數(shù)據(jù)刪除引擎，而數(shù)據(jù)塊的大小比數(shù)據(jù)庫頁面還小，那么情況也很糟糕。