Thanks for that Bill. Now I understand why there is the option to specify
the pools in the schedules something I always thought unnecessary.
I'm still puzzled why the pool clause is required in the job when the full
etc is given. Is it just a parser quirk?
Regards
Chris Wilkinson
On Wed, 4 May 2022, 6:43 am Bill Arlofski via Bacula-users, <
bacula-users@lists.sourceforge.net> wrote:
> On 5/3/22 15:46, Chris Wilkinson wrote:
> > I wonder if someone with more extensive knowledge of Bacula could
> clarify the usage of 'pool=' and the optional
> > 'full|differential|incremental backup pool=' directives in the job
> resource. The former is required I think whether or not
> > the latter is given.
> >
> > Since the latter will override the former, there doesn't seem any reason
> why the former should *always* be required?
> >
> > The reason I ask is that the Bacula module for Webmin shows the upcoming
> jobs for the next day. This info also includes the
> > pool that will be used. Webmin always take the pool from the pool=
> directive irrespective of the pool override given.
> >
> > Regards
> > Chris Wilkinson
>
> Hello Chris,
>
> As you know, 'Pool' is required in a Job{} resource for the parser to be
> happy. Even if it is pulled in via a JobDefs{}
> resource, a Pool is required.
>
> The 'full|differential|incremental backup pool=' directives are a great
> feature that I like to use all the t
> ime - well, we
> can discuss the times that they get in the way later... But they are a
> nice feature. (cough cough Copy/Migration jobs...)
>
> Here is why:
>
> Let's say you you need to run a spontaneous/manual Full job... And let's
> say that the Job{} resource has a 'Pool = Default'
> (or Pool = SomeIncPool) set in it because this job normally runs via
> schedule where you have Pool and Level overrides in the
> Schedule depending on the day...
>
> Well, without the FullBackupPool set, this manual job would use the
> 'Default' Pool (or whatever Pool was set to in the job).
>
> If you did not remember to set the `pool=` on the bconsole `run` command
> line, or modify the Pool before finally submitting
> the Job, the Job would use whatever pool was set in the Job's 'Pool='
> setting.
>
> If the FullBackupPool was set in this job, you can be sure that in this
> example of a manually overridden level set to Full,
> the job would use the correct Full pool automatically, and not write a
> full job to a 'defau
> lt' pool or other pool. And you
> would not need to remember to change the `pool=` (and probably the
> `storage=`) before submitting the job to run.
>
> This is also true for the cases when an incremental job gets automatically
> upgraded to a Full by Bacula because a Full does
> not exist in the catalog, or the MaxFullInterval has passed, causing the
> same situation... These types of submitted jobs that
> would normally use the "Pool=IncPool" setting to write a Full backup to,
> would now, instead *always* use the correct pool for
> the level of the job - even when it gets manually or automatically
> upgraded, or modified.
>
> I use these settings together with the MaxFullInterval setting so I have
> no overrides in my schedules, and Bacula just knows
> that after 31 days it is time to run this job as a full, and also knows
> what pool (full, Inc, or Diff) to write too.
>
> Well, actually only Inc and Full since my Jobs have 'Level = Incremental'
> in them, and when they MaxFullInterval
> automatically
> upgrades the job to a Full, the correct Full pool is used.
>
>
> Hope this helps!
>
>
> Best regards,
> Bill
> --
> Bill Arlofski
> w...@protonmail.com
> _______________________________________________
> Bacula-users mailing list
> Bacula-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bacula-users
>
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
