From the statistics you show, the backup does not appear slow to me. The reason you might think it is slow is because you are comparing apples and oranges.
On the one hand, you measure the time to to a non-compressed tar on a local machine sending the output down an extremely hi-speed bit bucket. On the other hand, you measure the time of Bacula using compression sending real data to another process via TCP/IP (even though it might be on the same machine). To do a better comparison, you could run tar including the z option so that it does compression. In addition, you should send the output of tar across the network and write it to either a file or a tape (whatever Bacula is using). At that point, providing you are always doing Full backups on Bacula (and not Incremental of Differential), you will probably find that the total Bacula time is not terribly greater than tar. That said, Bacula will amost always be slower than tar because it does a whole lot more -- in addition to checksuming all the data Bacula writes to the Volume, which I am not sure tar does, Bacula also interfaces to a database and stores a lot of information about the job. If you want to do additional performance testing you can look at <bacula-source>/src/version.h. There are various configuration parameters that you can turn on/off and then re-build Bacula and measure the performance of particular parts. Performance testing is a highly evolved science as well as an art, and it is not always easy. For example, if you are going to do any timing experiments as you did, you *must* on Unix systems re-run the test at least 10 times, throw out the first two timings, then take an average of the remaining 8. If you don't do this, your timing tests will have no meaning due to the memory cacheing that Unix does. Best regards, Kern
