本文將考慮備份軟體，該軟體透過將資料流分解為單獨的元件（區塊）來形成儲存庫。
儲存庫元件可以進一步壓縮和加密，最重要的是 - 在重複備份過程中 - 重複使用。
此類儲存庫中的備份副本是彼此連接的命名元件鏈，例如基於各種雜湊函數。
有幾個類似的解決方案，我將重點放在其中的 3 個：zbackup、borgbackup 和 Restic。
預期成績
由於所有申請人都需要以一種或另一種方式建立儲存庫，因此最重要的因素之一是估計儲存庫的大小。 理想情況下，根據公認的方法，其大小不應超過 13 GB，甚至更小 - 需要進行良好的最佳化。
我們也非常希望能夠直接建立檔案的備份副本，而無需使用 tar 等歸檔程序，並且無需使用 rsync 和 sshfs 等其他工具即可使用 ssh/sftp。
建立備份時的行為：
- 儲存庫的大小將等於或小於更改的大小。
- 使用壓縮和/或加密時，預計 CPU 負載會很高，如果歸檔和/或加密過程在備份儲存伺服器上運行，則可能會出現相當高的網路和磁碟負載。
- 如果儲存庫損壞，在建立新備份和嘗試還原時都可能出現延遲錯誤。 有必要規劃額外的措施來確保儲存庫的完整性或使用內建工具來檢查其完整性。
使用 tar 作為參考值，如先前的一篇文章所示。
測試 zbackup
zbackup的一般機制是程式在輸入資料流中尋找包含相同資料的區域，然後選擇性地壓縮和加密它們，每個區域只保存一次。
重複資料刪除使用帶有滑動視窗的 64 位元環雜湊函數來檢查與現有資料區塊的逐位元組匹配（類似於 rsync 的實作方式）。
多執行緒lzma和lzo用於壓縮，aes用於加密。 最新版本能夠在未來從儲存庫中刪除舊資料。
該程式是用 C++ 編寫的，具有最小的依賴性。 作者顯然受到了unix-way的啟發，因此該程式在創建備份時接受stdin上的數據，在恢復時在stdout上產生類似的數據流。 因此，在編寫自己的備份解決方案時，zbackup 可以用作非常好的「建構塊」。 例如，文章作者從大約 2014 年開始就使用該程式作為家用機器的主要備份工具。
除非另有說明，資料流將是常規 tar。
讓我們看看結果是什麼：
作品有 2 個選項進行檢查：
- 建立儲存庫並在伺服器上啟動包含來源資料的 zbackup，然後將儲存庫的內容傳輸到備份儲存伺服器。
- 在備份儲存伺服器上建立儲存庫，透過 ssh 在備份儲存伺服器上啟動 zbackup，並透過管道將資料傳送到它。
第一個選項的結果如下：43m11s - 當使用未加密的儲存庫和 lzma 壓縮器時，19m13s - 當用 lzo 取代壓縮器時。
原始資料伺服器上的負載如下（顯示了 lzma 的範例；lzo 的情況大致相同，但 rsync 的份額約為時間的四分之一）：
顯然，這樣的備份過程僅適用於相對罕見且較小的變更。 強烈建議將 zbackup 限制為 1 個線程，否則 CPU 負載會非常高，因為該程式非常擅長在多線程中工作。 磁碟上的負載很小，這對於現代基於 SSD 的磁碟子系統來說通常不會被注意到。 您也可以清楚地看到將儲存庫資料同步到遠端伺服器的過程的開始；操作速度與常規 rsync 相當，並且取決於備份儲存伺服器的磁碟子系統的效能。 這種方法的缺點是需要儲存本地儲存庫，從而導致資料重複。
更有趣且更適合實踐的是第二個選項，直接在備份儲存伺服器上執行 zbackup。
首先，我們將檢查不使用 lzma 壓縮器加密的操作：
每次試運行的運行時間：
發射 1
發射 2
發射 3
39分45秒
40分20秒
40分3秒
7分36秒
8分3秒
7分48秒
15分35秒
15分48秒
15分38秒
如果使用 aes 啟用加密，結果非常接近：
加密後相同資料的運行時間：
發射 1
發射 2
發射 3
43分40秒
44分12秒
44分3秒
8分3秒
8分15秒
8分12秒
15分0秒
15分40秒
15分25秒
如果使用 lzo 將加密與壓縮結合起來，則如下所示：
營業時間：
發射 1
發射 2
發射 3
18分2秒
18分15秒
18分12秒
5分13秒
5分24秒
5分20秒
8分48秒
9分3秒
8分51秒
產生的儲存庫的大小相對相同，均為 13GB。 這意味著重複資料刪除工作正常。 另外，在已經壓縮的資料上，使用 lzo 效果顯著；就總運行時間而言，zbackup 接近 duplicity/duplicati，但落後於基於 librsync 的 2-5 倍。
優點是顯而易見的——節省備份儲存伺服器上的磁碟空間。 至於儲存庫檢查工具，zbackup的作者沒有提供；建議使用容錯磁碟陣列或雲端提供者。
總的來說，給人留下了非常好的印象，儘管該專案已經停滯了大約 3 年（最後一次功能請求大約在一年前，但沒有得到回應）。
測試 borgbackup
Borgbackup 是 attic 的一個分支，是另一個類似 zbackup 的系統。 它是用 python 編寫，具有一系列與 zbackup 類似的功能，但還可以：
- 透過保險絲掛載備份
- 檢查儲存庫內容
- 工作在客戶端-伺服器模式
- 對資料使用各種壓縮器，並在壓縮時啟發式確定檔案類型。
- 2 個加密選項，aes 和 blake
- 內建工具用於
績效檢查
borgbackup 基準測試 ssh://backup_server/repo/path local_dir
結果如下：
CZ-BIG 96.51 MB/秒（10 100.00 MB 全零檔案：10.36s)
RZ-BIG 57.22 MB/秒（10 100.00 MB 全零檔案：17.48s)
UZ-BIG 253.63 MB/秒（10 100.00 MB 全零檔案：3.94s)
DZ-BIG 351.06 MB/秒（10 100.00 MB 全零檔案：2.85s)
CR-BIG 34.30 MB/秒（10 100.00 MB 隨機檔案：29.15s)
RR-BIG 60.69 MB/秒（10 100.00 MB 隨機檔案：16.48s)
UR-BIG 311.06 MB/秒（10 100.00 MB 隨機檔案：3.21s)
DR-BIG 72.63 MB/秒（10 100.00 MB 隨機檔案：13.77s)
CZ-中 108.59 MB/秒（1000 1.00 MB 全零檔案：9.21s)
RZ-中 76.16 MB/秒（1000 1.00 MB 全零檔案：13.13s)
UZ-MEDIUM 331.27 MB/秒（1000 1.00 MB 全零檔案：3.02s)
DZ-MEDIUM 387.36 MB/秒（1000 1.00 MB 全零檔案：2.58s)
CR-MEDIUM 37.80 MB/秒（1000 1.00 MB 隨機檔案：26.45s)
RR-中 68.90 MB/秒（1000 1.00 MB 隨機檔案：14.51s)
UR-MEDIUM 347.24 MB/秒（1000 1.00 MB 隨機檔案：2.88s)
DR-中型 48.80 MB/秒（1000 1.00 MB 隨機檔案：20.49s)
CZ-小 11.72 MB/秒（10000 10.00 kB 全零文件：8.53s)
RZ-小型 32.57 MB/秒（10000 10.00 kB 全零文件：3.07s)
UZ-小 19.37 MB/秒（10000 10.00 kB 全零文件：5.16s)
DZ-小 33.71 MB/秒（10000 10.00 kB 全零文件：2.97s)
CR-小 6.85 MB/秒（10000 10.00 kB 隨機檔案：14.60s)
RR-小 31.27 MB/秒（10000 10.00 kB 隨機檔案：3.20s)
UR-小 12.28 MB/秒（10000 10.00 kB 隨機檔案：8.14s)
DR-小 18.78 MB/秒（10000 10.00 kB 隨機檔案：5.32s)
測試時，將使用壓縮啟發式來確定檔案類型（自動壓縮），結果如下：
首先，我們來看看沒有加密的情況下它是如何運作的：
營業時間：
發射 1
發射 2
發射 3
4分6秒
4分10秒
4分5秒
56s
58s
54s
1分26秒
1分34秒
1分30秒
如果啟用儲存庫授權（驗證模式），結果將接近：
營業時間：
發射 1
發射 2
發射 3
4分11秒
4分20秒
4分12秒
1分0秒
1分3秒
1分2秒
1分30秒
1分34秒
1分31秒
當啟動 aes 加密時，結果並沒有惡化太多：
發射 1
發射 2
發射 3
4分55秒
5分2秒
4分58秒
1分0秒
1分2秒
1分0秒
1分49秒
1分50秒
1分50秒
而如果將 aes 改為 blake，情況就會徹底好轉：
營業時間：
發射 1
發射 2
發射 3
4分33秒
4分43秒
4分40秒
59s
1分0秒
1分0秒
1分38秒
1分43秒
1分40秒
與 zbackup 的情況一樣，儲存庫大小為 13GB，甚至更小，這是普遍預期的。 我對運行時間非常滿意；它與基於 librsync 的解決方案相當，提供了更廣泛的功能。 我還很高興能夠透過環境變數設定各種參數，這在自動模式下使用 borgbackup 時提供了非常重要的優勢。 我對備份期間的負載也很滿意：從處理器負載來看，borgbackup 在 1 個執行緒中運作。
使用時沒有特別的缺點。
靜態測試
儘管 Restic 是一個相當新的解決方案（前 2 個候選方案早在 2013 年或更早的時候就已為人所知），但它具有相當好的特性。 用 Go 編寫。
與 zbackup 相比，它還提供：
- 檢查儲存庫的完整性（包括檢查部分）。
- 用於儲存備份的大量受支援協定和提供程序，以及對用於雲端解決方案的 rclone - rsync 的支援。
- 相互比較 2 個備份。
- 透過保險絲安裝儲存庫。
總的來說，功能清單與 borgbackup 非常接近，在某些地方更多，在其他地方更少。 其特點之一是無法停用加密，因此備份將始終加密。 讓我們看看在實踐中可以從這個軟體中擠出什麼：
結果如下：
營業時間：
發射 1
發射 2
發射 3
5分25秒
5分50秒
5分38秒
35s
38s
36s
1分54秒
2分2秒
1分58秒
效能結果也與基於 rsync 的解決方案相當，並且通常非常接近 borgbackup，但 CPU 負載更高（運行多個執行緒）並且呈鋸齒狀。
最有可能的是，該程式受到資料儲存伺服器上磁碟子系統效能的限制，就像 rsync 的情況一樣。 儲存庫大小為13GB，就像zbackup或borgbackup一樣，使用該解決方案時沒有明顯的缺點。
Результаты
事實上，所有候選人都取得了相似的結果，但付出了不同的代價。 Borgbackup 表現最好，restic 稍慢一些，zbackup 可能不值得開始使用，
如果它已經在使用，請嘗試將其變更為 borgbackup 或 Restic。
發現
最有希望的解決方案似乎是 Restic，因為... 他的能力與運行速度的比例是最好的，但我們現在不要急於下一個一般性結論。
Borgbackup 基本上沒有更差，但 zbackup 可能會更好地被取代。 確實，zbackup 仍然可以用來確保 3-2-1 規則發揮作用。 例如，除了基於 (lib)rsync 的備份工具之外。
公告
備份第 5 部分：測試適用於 Linux 的 bacula 和 veeam 備份
備份第 6 部分：比較備份工具
備份第 7 部分：結論
發表者： 帕維爾·德姆科維奇
來源： www.habr.com