Lloyd, [Before I hit send, and looking back at your original message, I am not sure if you can accomplish this. The docs say "Note, you define only a single Job to do the Full, Differential, and Incremental backups since the different backup levels are tied together by a unique Job name." here: https://www.bacula.org/9.4.x-manuals/en/main/Configuring_Director.html#SECTION002030000000000000000. Since the Duplicate Job Handling directives are part of the Job spec, you can't specify cancellation for Incremental backups but not Full, etc. within one Job spec.]
You can control duplicate jobs -- maybe this can be used to prevent the situation you are talking about. See: https://www.bacula.org/9.4.x-manuals/en/main/Released_Version_3_0_3_3_0_.html#SECTION0010210000000000000000 Also see: https://www.bacula.org/9.4.x-manuals/en/main/New_Features_in_5_2_13.html#SECTION00942000000000000000 ("Allow Higher Duplicates" basically replaced with "Cancel Lower Level Duplicates" in 5.0.1 as the former did not work correctly.) Also, the docs talk about disk-based backup using different pools for Incremental, Differential and Full here: https://www.bacula.org/9.4.x-manuals/en/main/Automated_Disk_Backup.html#SECTION002930000000000000000 If you get it working, I'd be interested in hearing about your final solution. -Jonathan Hankins On Mon, Jun 17, 2019 at 3:50 PM Lloyd Brown <lloyd_br...@byu.edu> wrote: > 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> 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 >> https://lists.sourceforge.net/lists/listinfo/bacula-users >> > > > -- > ------------------------------------------------------------------------ > Jonathan Hankins Homewood City Schools > > 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 Universityhttp://marylou.byu.edu > > -- ------------------------------------------------------------------------ Jonathan Hankins Homewood City Schools 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.
_______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
