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一直不能很好兼容新興的重複數據刪除技術，難免有點遺憾。