本文將比較備份工具，但首先您應該了解它們從備份還原資料的速度和效果如何。
為了便於比較，我們將考慮從完整備份恢復，特別是因為所有候選者都支援這種操作模式。為簡單起見，這些數字已被平均（多次運行的算術平均值）。結果將匯總在表格中，其中還包含有關功能的資訊：Web 介面的存在、設定和操作的簡易性、自動化的能力、各種附加功能的存在（例如，檢查資料完整性） ， ETC 。這些圖表將顯示將使用資料的伺服器（而不是用於儲存備份副本的伺服器）上的負載。
數據恢復
rsync 和 tar 將用作參考點，因為 用於製作備份副本的簡單腳本。
Rsync的 在 4 分 28 秒內處理完測試資料集，顯示
這樣的負載
復原過程遇到了備份儲存伺服器磁碟子系統的限制（鋸齒圖）。您還可以清楚地看到一個核心的加載，沒有任何問題（低 iowait 和 softirq - 磁碟和網路分別沒有問題）。由於另外兩個程序，即 rdiff-backup 和 rsnapshot，基於 rsync 並且還提供常規 rsync 作為復原工具，因此它們將具有大致相同的負載設定檔和備份還原時間。
柏油 做得更快一點
2分43秒：
由於軟中斷增加，系統總負載平均增加了 20%，即網路子系統運作期間的開銷成本增加。
如果進一步壓縮存檔，恢復時間將增加到 3 分 19 秒。
主伺服器上有這樣的負載（在主伺服器一側解壓縮）：
解壓縮過程會佔用兩個處理器核心，因為有兩個行程正在運作。總的來說，這是預期的結果。此外，在有備份的伺服器端執行gzip 時獲得了可比較的結果（3 分20 秒）；主伺服器上的負載設定檔與在沒有gzip 壓縮器的情況下執行tar 非常相似（請參閱上圖） 。
В rdiff-備份 您可以使用常規 rsync 同步上次所做的備份（結果將類似），但仍需要使用 rdiff-backup 程式恢復較舊的備份，該程式在 17 分 17 秒內完成了恢復，顯示
這個負載：
也許這是有意的，至少是為了限製作者的速度 。恢復備份副本的過程本身只需要不到一個核心的一半，並且透過 rsync 在磁碟和網路上具有按比例可比較的效能（即慢 2-5 倍）。
快照 對於恢復，它建議使用常規 rsync，因此其結果將相似。總的來說，結果是這樣的。
打p 我在 7 分 2 秒內完成了恢復備份的任務
以此負載：
它運行得相當快，而且至少比純 rsync 方便得多：你不需要記住任何標誌、簡單直觀的 cli 介面、對多個副本的內建支援 - 儘管它慢了兩倍。如果您需要從上次備份中恢復數據，可以使用 rsync，但有一些注意事項。
該程式顯示出大致相同的速度和負載 備份電腦 啟用 rsync 傳輸模式時，部署備份
7分42秒：
但在資料傳輸模式下，BackupPC 處理 tar 的速度較慢：在 12 分 15 秒內，處理器負載普遍較低
一倍半：
表裡不一 不加密的結果稍好一些，在 10 分 58 秒內恢復備份。如果使用 gpg 啟動加密，恢復時間將增加到 15 分 3 秒。此外，在建立用於儲存副本的儲存庫時，您可以指定拆分傳入資料流時將使用的存檔大小。一般來說，在常規硬碟上，同樣由於是單執行緒運作模式，並沒有太大的差別。使用混合儲存時，它可能會出現不同的區塊大小。恢復期間主伺服器的負載如下：
沒有加密
加密
重複 顯示出類似的恢復速度，在 13 分 45 秒內完成。又花了大約5分鐘檢查恢復資料的正確性（總共約19分鐘）。負載為
相當高：
當內部啟用 aes 加密時，恢復時間為 21 分 40 秒，恢復期間 CPU 使用率達到最大（兩個核心！）；檢查資料時，只有一個執行緒處於活動狀態，佔用一個處理器核心。恢復後檢查資料同樣花了 5 分鐘（總共將近 27 分鐘）。
導致
使用外部 gpg 程式進行加密時，duplicati 的復原速度要快一些，但總的來說，與先前模式的差異很小。運行時間16分30秒，數據驗證6分鐘。負載為
這樣的：
AMANDA，使用 tar，在 2 分 49 秒內完成了它，原則上，這與常規 tar 非常接近。原則上對系統進行負載
相同：
使用恢復備份時 備份 得到了以下結果：
加密、lzma 壓縮
片長11分8秒
AES 加密、lzma 壓縮
運行時間14分鐘
AES 加密、lzo 壓縮
片長6分19秒
總的來說，還不錯。這一切都取決於備份伺服器上處理器的速度，這可以從不同壓縮器下程式的運行時間清楚看出。在備份伺服器端，啟動了常規tar，因此如果與它相比，恢復速度要慢3倍。可能值得檢查多執行緒模式（具有兩個以上執行緒）下的操作。
博格備份 在未加密模式下，它比 tar 慢一點，需要 2 分 45 秒，但是，與 tar 不同的是，它可以對儲存庫進行重複資料刪除。負載結果是
下列：
如果啟用基於 blake 的加密，備份還原速度會稍慢。此模式下恢復時間為3分19秒，負載消失
像這樣：
AES加密稍慢，恢復時間為3分23秒，負載特別大
沒有改變：
由於Borg可以在多執行緒模式下工作，因此處理器負載最大，當啟動附加功能時，運行時間只會增加。顯然，以與 zbackup 類似的方式探索多線程是值得的。
雷斯蒂奇 應對恢復速度稍慢一些，手術時間為4分28秒。負載看起來像
如下：
顯然，恢復過程是在多個執行緒中進行的，但效率不如 BorgBackup 高，但在時間上與常規 rsync 相當。
同 備份 8分19秒即可恢復數據，負載為
這樣的：
負載還是不是很高，甚至比tar還低。有的地方有突發，但不超過一個核心的負荷。
比較標準的選擇和理由
如同先前的一篇文章所述，備份系統必須滿足以下條件：
- 使用方便
- 多功能性
- 穩定
- 迅速
值得更詳細地單獨考慮每一點。
操作方便
最好有一個按鈕“做好一切”，但如果你回到真實的程序，最方便的將是一些熟悉的標準操作原則。
如果大多數使用者不必記住一堆 cli 金鑰、透過 web 或 tui 配置一堆不同的、通常晦澀難懂的選項，或者設定有關不成功操作的通知，那麼他們很可能會過得更好。這還包括將備份解決方案輕鬆「適應」現有基礎設施的能力，以及備份過程的自動化。也可以使用套件管理器或透過一兩個命令（例如“下載並解壓縮”）進行安裝。 curl ссылка | sudo bash - 一個複雜的方法，因為您需要檢查透過連結到達的內容。
例如，在考慮的候選方案中，一個簡單的解決方案是 burp、rdiff-backup 和 Restic，它們具有針對不同操作模式的助記鍵。稍微複雜一點的是博格和口是心非。最困難的是阿曼達。其餘的在易用性方面則處於中間位置。無論如何，如果您需要超過 30 秒的時間來閱讀用戶手冊，或者您需要訪問 Google 或其他搜尋引擎，並滾動瀏覽一長串幫助信息，那麼無論如何，做出決定都是困難的。
一些被考慮的候選人能夠透過電子郵件jabber自動發送訊息，而其他候選人則依賴系統中配置的警報。此外，大多數複雜的解決方案都沒有完全明顯的警報設定。無論如何，如果備份程序產生非零回傳代碼，系統服務將正確理解該代碼以執行定期任務（訊息將發送給系統管理員或直接發送給監控） - 情況很簡單。但是，如果無法設定不在備份伺服器上執行的備份系統，則說明該問題的明顯方式是複雜性已經過高。無論如何，僅向 Web 介面或日誌發出警告和其他訊息是一種不好的做法，因為它們通常會被忽略。
至於自動化，一個簡單的程式可以讀取設定其操作模式的環境變量，或者它有一個開發的 cli，可以完全複製透過 Web 介面工作時的行為。這也包括持續營運的可能性、擴張機會的可用性等。
多功能性
部分呼應前一小節有關自動化的內容，將備份流程「適應」現有基礎設施應該不是一個特殊的問題。
值得注意的是，使用非標準連接埠（當然，除了 Web 介面）進行工作、以非標準方式實施加密、使用非標準協定交換資料都是非標準的標誌。- 通用解決方案。在大多數情況下，所有候選人都以某種方式擁有它們，原因很明顯：簡單性和多功能性通常不能同時存在。作為一個例外 - 打嗝，還有其他的。
作為標誌 - 使用常規 ssh 工作的能力。
工作速度
最有爭議、最有爭議的一點。一方面，我們啟動了該流程，它盡可能快地運行並且不干擾主要任務。另一方面，備份期間流量和處理器負載會激增。另外值得注意的是，最快的影印程式通常在對使用者重要的功能方面是最差的。再說一次：如果為了獲得一個帶有密碼的不幸的幾十字節大小的文本文件，並且因此而導致整個服務成本（是的，是的，我知道備份過程通常不應該歸咎於這裡），並且您需要按順序重新讀取儲存庫中的所有檔案或擴展整個存檔- 備份系統永遠不會很快。另一個經常成為絆腳石的點是從存檔部署備份的速度。對於那些只需將文件複製或移動到所需位置而無需太多操作（例如rsync）的人來說，這裡有一個明顯的優勢，但大多數情況下，必鬚根據經驗以組織方式解決問題：通過測量備份恢復時間並公開告知使用者此事。
穩定
應該這樣理解：一方面必須能夠以任何方式將備份副本部署回來，另一方面必須能夠抵抗各種問題：網路中斷、磁碟故障、刪除部分檔案儲存庫。
備份工具比較
副本建立時間
複製恢復時間
簡易安裝
設置簡單
方便使用
簡單的自動化
您需要客戶端伺服器嗎？
檢查儲存庫的完整性
差異副本
透過管道工作
多功能性
獨立
儲存庫透明度
加密
壓縮
重複資料刪除
網頁界面
填充至雲端
Windows 支援
標記
Rsync的
4分15秒
4分28秒
是的
沒有
沒有
沒有
是的
沒有
沒有
是的
沒有
是的
是的
沒有
沒有
沒有
沒有
沒有
是的
6
柏油
純
3分12秒
2分43秒
是的
沒有
沒有
沒有
沒有
沒有
是的
是的
沒有
是的
沒有
沒有
沒有
沒有
沒有
沒有
是的
8,5
GZIP
9分37秒
3分19秒
是的
Rdiff備份
16分26秒
17分17秒
是的
是的
是的
是的
是的
沒有
是的
沒有
是的
沒有
是的
沒有
是的
是的
是的
沒有
是的
11
快照
4分19秒
4分28秒
是的
是的
是的
是的
沒有
沒有
是的
沒有
是的
沒有
是的
沒有
沒有
是的
是的
沒有
是的
12,5
打p
11分9秒
7分2秒
是的
沒有
是的
是的
是的
是的
是的
沒有
是的
是的
沒有
沒有
是的
沒有
是的
沒有
是的
10,5
表裡不一
沒有加密
16分48秒
10分58秒
是的
是的
沒有
是的
沒有
是的
是的
沒有
沒有
是的
沒有
是的
是的
沒有
是的
沒有
是的
11
GPG
17分27秒
15分3秒
重複
沒有加密
20分28秒
13分45秒
沒有
是的
沒有
沒有
沒有
是的
是的
沒有
沒有
是的
沒有
是的
是的
是的
是的
是的
是的
11
AES
29分41秒
21分40秒
GPG
26分19秒
16分30秒
備份
沒有加密
40分3秒
11分8秒
是的
是的
沒有
沒有
沒有
是的
是的
是的
沒有
是的
沒有
是的
是的
是的
沒有
沒有
沒有
10
AES
42分0秒
14分1秒
AES+LZO
18分9秒
6分19秒
博格備份
沒有加密
4分7秒
2分45秒
是的
是的
是的
是的
是的
是的
是的
是的
是的
是的
沒有
是的
是的
是的
是的
沒有
是的
16
AES
4分58秒
3分23秒
布雷克2
4分39秒
3分19秒
雷斯蒂奇
5分38秒
4分28秒
是的
是的
是的
是的
沒有
是的
是的
是的
是的
是的
沒有
是的
沒有
是的
沒有
是的
是的
15,5
備份
8分21秒
8分19秒
是的
是的
是的
沒有
是的
沒有
是的
沒有
是的
是的
沒有
是的
是的
是的
是的
沒有
是的
12
阿曼達
9分3秒
2分49秒
是的
沒有
沒有
是的
是的
是的
是的
沒有
是的
是的
是的
是的
是的
沒有
是的
是的
是的
13
備份電腦
rsync的
12分22秒
7分42秒
是的
沒有
是的
是的
是的
是的
是的
沒有
是的
沒有
沒有
是的
是的
沒有
是的
沒有
是的
10,5
焦油
12分34秒
12分15秒
表圖例：
- 綠色，操作時間少於五分鐘，或回答「是」（「需要客戶端伺服器嗎？」欄除外），1分
- 黃色，操作時間0.5至XNUMX分鐘，XNUMX分
- 紅色，工作時間超過十分鐘，或回答「否」（「是否需要客戶端伺服器？」一欄除外），0分
根據上表，最簡單、最快、同時方便且功能強大的備份工具是BorgBackup。雷斯蒂奇則位居第二，其餘被考慮的候選人排名大致相同，最後相差一兩分。
我感謝所有閱讀本系列文章的人，我邀請您討論這些選項並提供您自己的選項（如果有）。隨著討論的進展，該表可能會擴大。
該系列的成果將是最後一篇文章，其中將嘗試開發一種理想、快速且可管理的備份工具，使您可以在最短的時間內部署回副本，同時又方便又容易配置和維護。
公告
備份第 6 部分：比較備份工具
備份第 7 部分：結論
來源： www.habr.com