On Monday 05 November 2007 17:25, [EMAIL PROTECTED] wrote: > 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.
Well, if you have this enabled, they will never be scheduled, and there will be no need to cancel, them as it will be done automatically. > > => > => 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) My last propose used the word HigherLevel, which is much clearer and which I prefer over Precedence. The exact names are still open to a certain discussion though. > > 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) I'm not too enthusiastic about that suggestion unless you can give me a good reason why you need to re-define the levels. The current level structure from high to low is Full, Differential, and Incremental. I don't see a need to change that. > > => > => 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. Yes, I think this simple mechanism will eliminate a lot of the problems associated with bottlenecks, unmounted tapes, long running jobs, vacations, ... I have another one I want to do too, which is to set a minimum period in which a Differential or Full is done, and automatically upgrade if one was missed. Regards, Kern > > 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.upen >n.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
