On 2019-12-13 12:26, Martin Simmons wrote: >> On Wed, 11 Dec 2019 09:32:51 +0100, Radosław Korzeniewski said:
>> On the other hand: >> - as I understand the main problem discussed here was resolved at least in >> Bacula Enterprise where you can create "linked job execution", so you can >> start copy job right after the main job terminates, right? > > It's good to hear that Bacula Enterprise has a solution, but I don't know > about it. > > >> - all you need for your copy job policy with priorities is to create a job >> which just execute a copy job at the right time > > Yes, but as Phil mentioned, it is difficult to choose the right time. The linked-job solution also has the problem that it only links to a single job, so it's only a partial solution. It will not work if you have five jobs A, B, C, D, E, and a copy job F which must run after ALL of A, B, C, D, E have finished, but you aren't certain which one will finish last. (In my case, this would not be an issue because I know that the Catalog Backup job is prioritized to run only after the others have completed, and therefore MUST ALWAYS be the last to finish.) I also don't know whether the linked-job implementation allows you to specify that the linked job be run ONLY on certain job levels. And in any case, the Bacula Enterprise feature - I hesitate to say solution - does not help anyone not using Enterprise. All of these problems go away if copy jobs do not evaluate their selection condition until they are actually ready to start, which I assert would be the behavior expected by probably 99% of Bacula users. Martin has already noted that in this regard they behave differently to all other job types, every other type evaluating its parameters only when it starts. Evaluating selection queries when queued, which may be many hours ahead of when it actually runs, almost ensures that when the job finally runs, it runs with stale and probably-incorrect data. This may very well indeed implement the current design, but that does not mean that this aspect of the design is right. I contend that this element of the design is in fact wrong. The fact that there are ways to work around it does not negate this. Radosław, you didn't answer Martin's question: Can you describe a realistic case where it is ever better for the user that a Copy job evaluate its selection criteria when it is queued, rather than when it actually starts? -- Phil Stracchino Babylon Communications ph...@caerllewys.net p...@co.ordinate.org Landline: +1.603.293.8485 Mobile: +1.603.998.6958 _______________________________________________ Bacula-devel mailing list Bacula-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-devel
