Jonathan, I appreciate the suggestion. As it happens, we're not using different devices. We're using file-based storage, and haven't ever seen the need to be careful to keep them in different pools, etc.
Also, I'm slightly confused by your idea. If I'm understanding you right, this wouldn't prevent the subsequent jobs of a particular type/job-spec (eg. incrementals for "job_x") from being queued to run. True, the data wouldn't have changed much in the meantime, but the backup is unnecessary, takes at least some extra space, and has some less-than-desirable side-effects (eg. delaying the lower-priority "BackupCatalog" job). Perhaps I'm not understanding your suggestion as well as I think. Lloyd On 6/14/19 4:42 PM, Hankins, Jonathan wrote: > If you use different devices for your full, incremental, etc. jobs, I > believe you can do it with this: > > https://www.bacula.org/9.4.x-manuals/en/main/New_Features_in_5_2_13.html#SECTION00951000000000000000 > > -Jonathan Hankins > > On Fri, Jun 14, 2019 at 3:26 PM Lloyd Brown <lloyd_br...@byu.edu > <mailto:lloyd_br...@byu.edu>> wrote: > > Is there a way to limit the number of queued Incremental jobs to 1, > while still allowing other types (eg. Full or VirtualFull) to be > queued > up? Historically I've used these parameters to prevent new jobs from > being queued up, when one is already running (in the Job or JobDefs > definition): > > > Maximum Concurrent Jobs = 1 > > Allow Duplicate Jobs = no > > If a job is still running when the next job comes up on the schedule, > that new job is then rejected with a "Duplicate job not allowed." > > That's the behavior I'd like, if the new job is an Incremental. > But if > it's something else (eg. Full or VirtualFull), I'd like it to be > allowed > to queue up, and wait for the incremental to finish (due to the > "Maximum > Concurrent Jobs = 1"), before running. > > Is this possible? Is my explanation clear? > > Thanks, > > Lloyd > > > -- > > Lloyd Brown > HPC Systems Administrator > Office of Research Computing > Brigham Young University > http://marylou.byu.edu > > > > _______________________________________________ > Bacula-users mailing list > Bacula-users@lists.sourceforge.net > <mailto:Bacula-users@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/bacula-users > > > > -- > ------------------------------------------------------------------------ > Jonathan Hankins Homewood City Schools > > jhank...@homewood.k12.al.us <mailto:jhank...@homewood.k12.al.us> > ------------------------------------------------------------------------ > > > This e-mail is intended only for the recipient and may contain confidential > or proprietary information. If you are not the intended recipient, the > review, distribution, duplication or retention of this message and its > attachments is prohibited. Please notify the sender of this error immediately > by reply e-mail, and permanently delete this message and its attachments in > any form in which they may have been preserved. -- Lloyd Brown HPC Systems Administrator Office of Research Computing Brigham Young University http://marylou.byu.edu
_______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
