本評論繼續
UrBackup 評論。
應參加者要求
在全備份模式下,得到以下結果:
營業時間:
第一次開始
二次發射
第三次發射
第一次測試
8分20秒
8分19秒
8分24秒
第二次測試
8分30秒
8分34秒
8分20秒
第三次測試
8分10秒
8分14秒
8分12秒
增量備份模式下:
營業時間:
第一次開始
二次發射
第三次發射
第一次測試
8分10秒
8分10秒
8分12秒
第二次測試
3分50秒
4分12秒
3分34秒
第三次測試
2分50秒
2分35秒
2分38秒
兩種情況下的儲存庫大小約為 14 GB,這表示重複資料刪除在伺服器端正常運作。 還應該注意的是,伺服器和用戶端上的備份建立時間之間存在差異,這從圖表中非常明顯可見,並且是一個非常令人愉快的好處,因為 Web 介面顯示了備份過程的運行時間伺服器端不考慮
客戶的情況。 一般來說,完整副本和增量副本的圖表是無法區分的。 唯一的區別可能是伺服器端的處理方式。 我還對冗餘系統上的低處理器負載感到滿意。
備份電腦評論
應參加者要求
使用rsync建立全量備份的方式,得到以下結果:
第一次開始
二次發射
第三次發射
第一次測試
12分25秒
12分14秒
12分27秒
第二次測試
7分41秒
7分44秒
7分35秒
第三次測試
10分11秒
10分0秒
9分54秒
如果您使用完整備份和 tar:
第一次開始
二次發射
第三次發射
第一次測試
12分41秒
12分25秒
12分45秒
第二次測試
12分35秒
12分45秒
12分14秒
第三次測試
12分43秒
12分25秒
12分5秒
在增量備份模式下,我必須放棄 tar,因為備份不是使用這些設定建立的。
使用rsync建立增量備份的結果是:
第一次開始
二次發射
第三次發射
第一次測試
11分55秒
11分50秒
12分25秒
第二次測試
2分42秒
2分50秒
2分30秒
第三次測試
6分00秒
5分35秒
5分30秒
一般來說,rsync 具有輕微的速度優勢;rsync 與網路的配合也更經濟。 使用 tar 作為備份程式時,CPU 使用率會降低,這可能會部分抵消此影響。 rsync 的另一個優點是它可以使用增量副本。 建立完整備份時儲存庫的大小是相同的,在增量副本的情況下為 16 GB - 每次執行 14 GB,這表示重複資料刪除有效。
阿曼達評論
應參加者要求
使用 tar 作為歸檔器並啟用壓縮的測試運行結果如下:
第一次開始
二次發射
第三次發射
第一次測試
9分5秒
8分59秒
9分6秒
第二次測試
0分5秒
0分5秒
0分5秒
第三次測試
2分40秒
2分47秒
2分45秒
此方案滿載一個處理器核心,但由於備份儲存伺服器端磁碟IOPS有限,無法實現較高的資料傳輸速度。 一般來說,設定比其他參與者稍微麻煩一些,因為該程式的作者不使用 ssh 作為傳輸,而是使用金鑰實現類似的方案,創建和維護成熟的 CA。 可以廣泛地限制客戶端和備份伺服器:例如,如果它們不能完全信任彼此,那麼您可以作為一個選項,透過將相應變數的值設為零來阻止伺服器啟動備份復原設定檔。 可以連接 Web 介面進行管理,但一般來說,配置的系統可以使用小型 bash 腳本(或 SCM,例如 ansible)完全自動化。 有一個用於設定儲存的有點不簡單的系統,這顯然是由於支援各種用於儲存資料的裝置(LTO 盒式磁帶、硬碟等)的廣泛清單。 另外值得注意的是,在本文討論的所有程式中,AMANDA 是唯一能夠偵測目錄重命名的程式。 一次運行的儲存庫大小為 13 GB。
公告
備份第 6 部分:比較備份工具
備份第 7 部分:結論
來源: www.habr.com