本說明討論透過在備份伺服器上建立存檔來執行備份的備份工具。
滿足要求的包括口是心非（具有 deja dup 形式的漂亮介面）和 duplicati。
另一個非常出色的備份工具是 dar，但由於它有非常廣泛的選項清單 - 測試方法僅涵蓋其功能的 10% - 我們不會將其作為當前週期的一部分進行測試。
預期成績
由於兩位候選人都以某種方式建立檔案，因此可以使用常規 tar 作為指導。
此外，我們將透過建立僅包含完整副本與檔案目前狀態之間的差異或先前存檔與目前存檔之間（增量、減量等）的備份副本來評估儲存伺服器上資料儲存的最佳化程度。 。
建立備份時的行為：
- 備份儲存伺服器上的檔案數量相對較少（與備份副本的數量或以 GB 為單位的資料大小相比），但其大小相當大（數十到數百兆位元組）。
- 儲存庫大小將僅包含變更 - 不會儲存重複項，因此儲存庫大小將小於基於 rsync 的軟體。
- 使用壓縮和/或加密時，CPU 負載預計會很高，如果歸檔和/或加密進程在備份儲存伺服器上運行，則網路和磁碟負載可能會很高。
讓我們執行以下命令作為參考值：
cd /src/dir; tar -cf - * | ssh backup_server "cat > /backup/dir/archive.tar"執行結果如下：
執行時間3分12秒。可以看出，速度受到備份儲存伺服器的磁碟子系統的限制，如範例所示 。只是快一點，因為…錄音到一個文件。
另外，為了評估壓縮，讓我們運行相同的選項，但在備份伺服器端啟用壓縮：
cd /src/dir; tar -cf - * | ssh backup_server "gzip > /backup/dir/archive.tgz"結果是：
執行時間10分11秒。最有可能的瓶頸是接收端的單流壓縮機。
相同的命令，但透過壓縮將原始資料傳輸到伺服器，以測試瓶頸是單執行緒壓縮器的假設。
cd /src/dir; tar -czf - * | ssh backup_server "cat > /backup/dir/archive.tgz"結果是這樣的：
執行時間為9分37秒。壓縮機對一個核心的負載清晰可見，因為網路傳輸速度和來源磁碟子系統上的負載相似。
要評估加密，您可以透過連接附加命令來使用 openssl 或 gpg openssl 或 gpg 在管道中。作為參考，會有這樣的指令：
cd /src/dir; tar -cf - * | ssh backup_server "gzip | openssl enc -e -aes256 -pass pass:somepassword -out /backup/dir/archive.tgz.enc"結果是這樣的：
執行時間為 10 分 30 秒，因為接收端有 2 個進程正在運作 - 瓶頸又是單執行緒壓縮器，加上少量的加密開銷。
UPD： 應 bliznezz 的要求，我添加了 Pigz 測試。如果只使用壓縮器，需要6m30s，如果還加上加密，則需要7m左右。底部圖中的凹陷是未刷新的磁碟快取：
重複測試
Duplicity 是一款 Python 軟體，透過建立 tar 格式的加密檔案來進行備份。
對於增量存檔，使用 librsync，因此您可以預期中描述的行為 .
可以使用 gnupg 對備份進行加密和簽名，這在使用不同的提供者儲存備份（s3、backblaze、gdrive 等）時非常重要
讓我們看看結果是什麼：
這些是我們在不加密的情況下運行時得到的結果
劇透
每次試運行的運行時間：
發射 1
發射 2
發射 3
16分33秒
17分20秒
16分30秒
8分29秒
9分3秒
8分45秒
5分21秒
6分04秒
5分53秒
以下是啟用 gnupg 加密且金鑰大小為 2048 位元時的結果：
加密後相同資料的運行時間：
發射 1
發射 2
發射 3
17分22秒
17分32秒
17分28秒
8分52秒
9分13秒
9分3秒
5分48秒
5分40秒
5分30秒
顯示的區塊大小為 512 兆字節，這在圖表中清晰可見；處理器負載實際上保持在 50%，這意味著程式使用的處理器核心不超過一個。
該程式的運作原理也非常清晰可見：他們獲取一段數據，將其壓縮，然後將其發送到備份儲存伺服器，這可能會非常慢。
另一個特點是程式的可預測運行時間，該時間僅取決於更改資料的大小。
啟用加密並沒有顯著增加程式的運行時間，但它使處理器負載增加了大約 10%，這可以說是一個相當不錯的獎勵。
不幸的是，這個程式無法正確檢測目錄重命名的情況，結果儲存庫大小等於更改的大小（即全部 18GB），但可以清楚地使用不受信任的伺服器進行備份涵蓋了這種行為。
重複測試
該軟體是用 C# 編寫的，並使用 Mono 的一組庫運行。有 GUI 和 CLI 版本。
主要功能的大致清單與 duplicity 類似，包括各種備份儲存供應商，但是，與 duplicity 不同的是，大多數功能無需第三方工具即可使用。這是優點還是缺點取決於具體情況，但對於初學者來說，立即列出所有功能可能會更容易，而不是像現在這樣額外安裝 python 包口是心非的情況。
另一個小細微差別 - 程式會代表啟動備份的使用者主動寫入本機 SQLite 資料庫，因此您還需要確保每次使用 cli 啟動程序時正確指定所需的資料庫。當透過 GUI 或 WEBGUI 工作時，詳細資訊將對使用者隱藏。
我們來看看這個方案能產生什麼指標：
如果關閉加密（WEBGUI不建議這樣做），結果如下：
營業時間：
發射 1
發射 2
發射 3
20分43秒
20分13秒
20分28秒
5分21秒
5分40秒
5分35秒
7分36秒
7分54秒
7分49秒
啟用加密後，使用 aes，它看起來像這樣：
營業時間：
發射 1
發射 2
發射 3
29分9秒
30分1秒
29分54秒
5分29秒
6分2秒
5分54秒
8分44秒
9分12秒
9分1秒
如果使用外部程式 gnupg，則會出現以下結果：
發射 1
發射 2
發射 3
26分6秒
26分35秒
26分17秒
5分20秒
5分48秒
5分40秒
8分12秒
8分42秒
8分15秒
正如您所看到的，該程式可以在多個執行緒中工作，但這並不意味著它是一個更有效率的解決方案，如果您比較加密工作，它正在啟動一個外部程序
事實證明比使用 Mono 集中的庫更快。這可能是由於外部程式更加優化所致。
另一個好處是儲存庫的大小與實際變更的資料完全相同，即duplicati 偵測到目錄重新命名並正確處理了這種情況。執行第二個測試時可以看到這一點。
總體而言，對該計劃的印象相當積極，包括對新手相當友好。
Результаты
兩位候選人的工作速度都相當慢，但總的來說，與常規 tar 相比，至少在複製方面有所進步。這種進步的代價也很明顯──一個明顯的負擔
處理器。整體來說，預測結果沒有特別的偏差。
發現
如果您不需要趕到任何地方，並且也有一個備用處理器，那麼所考慮的任何解決方案都可以，無論如何，已經完成了相當多的工作，不應該通過在tar 上編寫包裝器腳本來重複這些工作。如果無法完全信任用於儲存備份副本的伺服器，則加密的存在是非常必要的屬性。
與基於解決方案的比較 - 儘管事實上 tar 的純粹形式比 rsync 快 20-30%，但性能可能會差幾倍。
儲存庫的大小可以節省，但僅限於重複項。
公告
備份第 3 部分：審查和測試口是心非、重複、似曾相識
備份第 4 部分：審查和測試 zbackup、restic、borgbackup
備份第 5 部分：測試適用於 Linux 的 bacula 和 veeam 備份
備份第 6 部分：比較備份工具
備份第 7 部分：結論
發表者： 帕維爾·德姆科維奇
來源： www.habr.com