Hello,

Here is a suggestion that I've had for Bacula. We haven't yet moved to  
3.x so this comes from some frustrations with 2.x that we've worked  
with:

Item X:   Decouple Jobs and Pools from storage daemon Devices
   Origin: Jesse Peterson <jesse.peterson AT exbiblio DOT com>
   Date:   04 September 2008
   Status:

   What:   Allow a Job or Pool to be associated with a "class" of  
device --
           most intuitively a Media Type. Under this type of operation  
the
           storage daemon would not be tied to a single storage daemon  
Device
           but rather would be allowed to pick the most "appropriate"  
device.
           For example if the Job/Pool were tied to a Media Type then  
any
           device that is appropriate (i.e. has a labeled, Append-able  
volume
           in the matching Pool mounted) is eligible to be used for that
           job. Furthermore Jobs would be able to use different  
devices when,
           e.g. a volume becomes full. Additionally this would also  
enable
           concurrent backup jobs using the same Pool to be writing to  
two
           different devices.

   Why:    For simpler management of Jobs and Pools and where you have  
many
           devices and some concurrent Jobs. As a simple example if you
           have, say, two tape drives you could label an "overflow"  
volume
           in your second drive in which Bacula would automatically,  
without
           intervention, start to use when your first volume gets  
used. Or
           if you had two auto-changers you might be able to have more
           efficient (faster) backups by doing concurrent jobs without
           having to dole out specific devices on a per-Job basis.

   Notes:  Perhaps a way to implement this might be to create a pseudo- 
device
           "container" that is just a meta-device that contains other
           devices. This container just looks at the status of devices  
at
           volume reservation time (Job start, volume full/new volume,  
etc.)
           and then hands-off or proxies the rest of the operation to  
the
           actual device. Just a thought.

           An alternative "concurrent" methodology might be automatic  
tape
           capacity balancing. I.e. when a Job starts the Device  
selected is
           the one with the volume with the least amount of data on it.
           Though this does imply what seems like very complicated  
logic of
           "partial/tape-spanning" jobs including (possibly) resuming  
a job
           from a full volume onto a non-full volume. Perhaps more
           importantly I am not certain of a practical real-world use  
of such
           a methodology. :) Seems like an autochanger could be used  
here
           instead.


----


Thanks,
- Jesse


P.S. Please reply-all as I subscribe to the digest and may not  
immediately see replies. Thank you.


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users