I currently have 3 clients doing a full backup (simultaneously). According to “status client” one is getting 300kb/s (this one is my director and storage server machine), one is getting 225kb/s, and one is getting 50kb/s. I’ve disabled AV on access scanning for the bacula-fd.exe process. I have software compression enabled, but none of the 3 systems seem bogged down so I think the bottleneck is not due to that option (although I’m tempted to turn on ntfs compression on the backup drive and disable software compression in the future).

For the most part I don’t mind too much that the backups are so slow because I’m quite happy to see the client machines continuing to be quite snappy. The main concern, particularly for full backups (which at this rate will take upwards of 3 days to complete), is the possibility of a system going offline and thus killing the backup (or will it pick up where it left off, as long as I have FD Connect Timeout configured to be longer than a system would typically be offline for, e.g. 12 hours?).

So what else could be coming into play with my poor performance? Are simultaneous backups problematic performance-wise? I’ve watched the I/O activity of bacula-sd.exe and it certainly doesn’t seem to be maxed out. It is using an external USB2 hard drive. Could the difference between USB2 and eSATA be the key? I can connect them as eSATA if I really need to. Seems like USB2 should be allowing substantially more than the roughly 600kb/s overall speed I’m getting though.

I’m running all Windows Bacula binaries, version 3.0.3. I’m not sure posting config files is necessary at this point, although I’m happy to do so if needed.