In the message dated: Sun, 04 Nov 2007 18:09:51 +0100,
The pithy ruminations from Kern Sibbald on
<[Bacula-users] Mini project> were:
=> Hello,
=>
=> Although I am working on a rather large project that I would like to explain
a
=> bit later when I have made some real progress (probably after the first of
=> the year), I am thinking about doing a little mini-project to add a feature
=> that has always bothered me, and that is the fact that Bacula can at times
=> when there are failures or bottlenecks have a lot of Duplicate jobs running.
Great idea!
=> So, I'm thinking about adding the following two directives, which may not
=> provide all the functionality we will ever need, but would go a long way:
=>
=> These apply only to backup jobs.
=>
=> 1. Allow Duplicate Jobs = Yes | No | Higher (Yes)
=>
=> 2. Duplicate Job Interval = <time-interval> (0)
=>
=> The defaults are in parenthesis and would produce the same behavior as today.
=>
=> If Allow Duplicate Jobs is set to No, then any job starting while a job of
the
=> same name is running will be canceled.
Will that also apply to pending jobs? For example, if one of our large full
backups (2+TB) is running, a few days of incrementals for other clients may be
scheduled and pending, but not actually running. I'd be happy seeing the
automatic cancellation of duplicates applied to pending jobs--even if no job of
that name is running yet.
=>
=> If Allow Duplicate Jobs is set to Higher, then any job starting with the
same
=> or lower level will be canceled, but any job with a Higher level will start.
=> The Levels are from High to Low: Full, Differential, Incremental
Is it possible to reword this? The description introduces several points of
possible confusion:
1. "level" sounds a lot like "priority"
2. it's inconsistent that "higher" levels take precendence over "lower"
levels, but that "lower" priorities take precendence over
"higher" (numeric) priorities
3. a fixed choice of "Higher" may not always be appropriate in
different environments.
For example, if I've got a pending Full backup and a pending
Incremental, I might want the Incremental to take precendence,
since it will be relatively quick, and then the Full will be
automatically rescheduled (since it wasn't run) after the
Incremental completes.
What about having the syntax be:
Allow Duplicate Jobs = Yes | No | Precendence (Yes)
and adding yet-another-option:
Duplicate Precedence List = comma separated list of backup levels, in
user-defined priority order from left to right, as in
"Full, Incremental, Differential" (default = Null)
=>
=> Finally, if you have Duplicate Job Interval set to a non-zero value, any job
=> of the same name which starts <time-interval> after a previous job of the
=> same name would run, any one that starts within <time-interval> would be
=> subject to the above rules. Another way of looking at it is that the Allow
=> Duplicate Jobs directive will only apply after <time-interval> of when the
=> previous job finished (i.e. it is the minimum interval between jobs).
That would be very helpful.
Thanks,
Mark
=>
=> Comments?
=>
=> Best regards,
=>
=> Kern
=>
=> PS: I think the default for Allow Duplicate Jobs should be Higher, but that
=> would change current behavior ...
=>
----
Mark Bergman [EMAIL PROTECTED]
System Administrator
Section of Biomedical Image Analysis 215-662-7310
Department of Radiology, University of Pennsylvania
http://pgpkeys.pca.dfn.de:11371/pks/lookup?search=mark.bergman%40.uphs.upenn.edu
The information contained in this e-mail message is intended only for the
personal and confidential use of the recipient(s) named above. If the reader of
this message is not the intended recipient or an agent responsible for
delivering it to the intended recipient, you are hereby notified that you have
received this document in error and that any review, dissemination,
distribution, or copying of this message is strictly prohibited. If you have
received this communication in error, please notify us immediately by e-mail,
and delete the original message.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
