The way I have it set up is storage=“sd backup storage” defined in the backup jobs, undefined in the backup pools (job overrides) storage=“sd copy/migrate storage” undefined in the copy/migrate jobs, defined in the copy/migrate pools (pool overrides always)
Best -Chris- > On 9 Aug 2024, at 16:55, Bill Arlofski <w...@protonmail.com> wrote: > > On 8/9/24 4:51 AM, Chris Wilkinson wrote: > >> Just an aside - I realised whilst editing the jobs that the storage=“sd > >> used for backup jobs" should be specified in the Job >> resource, it’s not necessary (or desirable) to specify the storage in the >> Pool as well since the job overrides the pool. > > > Just a correction here. > > If you specify a `Storage = ` in a Pool, it cannot be overridden anywhere - > not in a JobDefs, not in a Job, not in a Schedule, not on the command line, > and not even when modifying it just before the final submission of a job. > > This, in my opinion is a bug as I belief that when an admin overrides > something, they should be believed that they know what they are doing and > that should be the final word. :) > > >> This doesn’t seem to be the case for Copy/Migrate Jobs, the storage=“sd used >> for copy jobs" has the be specified in every Pool used for copy jobs. Am I >> right that there is no equivalent override mechanism for Copy/Migrate jobs? > > The Storage for Copy/Migration control jobs needs to be in the source Pool, > or in the Copy/Migration control job itself. I don't have time to test, but > it may be possible to override the Pool and Storage for these in a Schedule > or on the command line, but that would make no sense to do. :) > > > Hope this helps, > Bill > > -- > Bill Arlofski > w...@protonmail.com >
_______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
