[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bacula-devel] feature request


On Tuesday 29 July 2008 15:22:03 T. Horsnell wrote:
> What:
> That Bacula be modified to enable the simultaneous use of multiple tape
> drives, either as a bunch of freestanding units or as multiple drives in
> an autochanger.
> Why:
> For me personally, this would permit faster simpler backup of a large
> single filesystem. I have a two-drive LTO4 tapechanger and at present,
> in order to utilise both drives at once, I have to create two jobs each
> of which backs up part of the filesystem. This is not optimal as the two
> subparts can change size radically, meaning that one drive may spend
> much of its time idle. I also have to split my tapes into two pools, one
> for each job.
> I have seen one other similar request to the users list recently,
> whereby a user had a bynch of freestanding drives which he wanted to
> preload with a set of tapes once a week, and then have Bacula
> automatically organise his backup over the tapes as it saw fit.
> This may make a cheap alternative to a tapechanger.
> A device pool maybe?

Technically I don't know how to do this project.   The SD has blocks of data 
coming in from the FD, and sending those blocks to multiple drives would be 
extremely difficult to track -- I am not even sure how.  Currently, they are 
either sequential (if spooling is on) or at least written in order to a 
single drive, so it is very easy to track and find them for restores.

In addition, I don't think it is possible for any existing network connection 
to run fast enough to drive an LTO4 tape drive at full speed, so this project 
seems to add a lot of complexity to Bacula to give no improvement in 
performance.  If I am wrong about the network connection and an LTO4, please 
show me the math :-)

For the moment I cannot accept the Feature Request.  If you can give complete 
details of a design for tracking the blocks written to multiple tapes and how 
to send them back to the FD in the same order, and if you can show with a 
simulation that we would actually gain something, then you can resubmit it, 
and I will reconsider adding it to the projects.  After than, either someone 
must submit a patch or the Bacula users vote and it becomes a top rated 
project, in which case one of the developers would surely work on it.

Best regards,


PS: Normally, I don't veto a Feature Request even if I am not much in favor of 
it unless it involves license problems (using proprietary interfaces) or is 
technically not possible as is the current request as written.

This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
Bacula-devel mailing list

This mailing list archive is a service of Copilotco.