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一直不能很好兼容新兴的重复数据删除技术，难免有点遗憾。

转载于:https://www.cnblogs.com/opennaive/archive/2011/11/15/3312761.html