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.peter...@exbiblio.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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
