Bacula測試報告

0.實驗準備

為了能測試bacula的效能，我在兩臺伺服器上搭建了bacula平臺，分別稱為53和62。在62上安裝了全部三方，而在53上只安裝Storage Daemon和File Daemon。一共準備3種資料集，分別是document、source和video，它們代表了不同數量級的平均檔案大小，詳細資訊如下：

檔案集	大小（MB）	檔案數	檔案平均大小
Document	503	269	1.87MB
Source	429	40942	10.74KB
Video	688	2	344MB

為此設計了4*3=12次備份，分別用不同的Storage和Client備份這三個檔案集。

1.備份

一共進行了12次備份，實驗結果如果所示（橫座標表示備份資料量的流向，53fd-62sd表示從53備份到62）。

53fd-53sd和62fd-62sd不經過網路傳輸，僅僅將資料備份在本地。可以看到不論是53還是62，document檔案集和video檔案集表現相當，而source檔案集由於都是小檔案效能下降明顯。同時可以看出53的效能要比62好很多。

53fd-62sd和62fd-53fd都經過網路傳輸，將資料從一臺伺服器備份到另一臺伺服器上。可以看出從兩個方向上備份三個檔案集的效能差不多， 都有10MB/s左右，所以網路備份的主要瓶頸是100Mbps的區域網頻寬，而不是53、62的伺服器效能差異以及檔案集差異。

比較62fd-62sd和53fd-62sd，可以發現本地備份source檔案集的效能居然不如網路備份source檔案集的效能，所以bacula對小檔案的網路傳輸進行了優化，而且這種優化對於本地備份效果不好，62fd-62sd備份source檔案集的瓶頸可能是62的小寫效能。

2.恢復

對之前12次備份分別進行恢復，實驗結果如圖所示。

比較53-sd-53fd和62sd-62fd，可以發現兩臺伺服器的表現差不多，證明兩者的讀寫效能並沒有很大的差異，而兩臺伺服器的備份效能卻差別很大，可能的原因是62的檔案分佈更加分散，導致了很多隨機訪問。而由於資料在卷中是順序擺放的，所以不存在隨機訪問的問題，因此兩臺伺服器的效能差別不大。這就解釋了62的本地恢復比本地備份要快很多。

比較53sd-62fd和62sd-53fd，三種檔案集的效能都能達到10MB/s左右，所以網路恢復的效能瓶頸仍然是100Mbps的頻寬。

比較53的本地備份和恢復，發現備份比恢復的吞吐率要高，這是比較少見的，原因不明。

3.小結

從這個簡單的測試中，可以看出對小檔案的處理是bacula的一個亮點，其卷的讀寫以Block為讀寫單位，避免了小讀小寫操作。但可能由於卷格式的設計具有一定的侷限性，導致bacula一直不能很好相容新興的重複資料刪除技術，難免有點遺憾。