>>>>> On Tue, 3 Dec 2019 15:15:53 +0100, Radosław Korzeniewski said: > > Hello, > > wt., 3 gru 2019 o 14:27 Martin Simmons <mar...@lispworks.com> napisał(a): > > > Is the current timing useful for some other situation? > > > > I do not understand your question.
I'm trying to understand why it is implemented like it is. I hope we agree that jobs have a scheduled time and a start time. The start time can be much later than the scheduled time, for example if the job priority is specified and a job with a smaller priority is running. A copy job currently chooses the jobs to be copied at the scheduled time(A), but Phil and myself think that it should choose the jobs to be copied at the start time(B). Can you explain if (A) is ever better than (B) for the user? Please don't just say "(A) is better because it is implemented like that" because I want to focus on making Bacula more useful for a user. > > > > It seems like a bug to me too. To continue your analogy, it is like the > > restaurant forcing you to choose a dish when you book the table, before > > you've > > seen the menu of the day. > > > > No, absolutely not. When you execute the copy job then all required data is > available and copy jobs simply start, so the menu is available when you > book a table. > But when you go to the restaurant then an admin stop you entering the room > and force you wait until the next day when menu changed - so it is not a > surprise. > Admin should not prevent a copy job from executing. This is the main issue > here in the code which is currently available. > > If you think it should work differently then you have to implement a > different kind of mechanism. And as I understand Heitor's answer the > solution is to link copy job with source job using Run=... directive. Then > your copy job will be executed when your source job finish. The job priority is an existing mechanism that is used to delay the start time of a job for many related situations. It doesn't work for copy jobs because Bacula chooses the jobs to be copied at the scheduled time. > > Compare it with VolumeToCatalog verify jobs for example, which select the > > job > > when they start, not when they are scheduled. > > > > Yes. This is exactly the same situation. > > There is NO any link between source backup jobs and any Copy/Migrate/Verify > jobs (except the functionality described by Heitor), so it is impossible to > achieve what you request. It is how it was designed and implemented. You > could expect a different functionality so it should be designed and > developed. From a technical point of view we have to add another indirect > stage for job execution which will evaluate job execution parameters just > right before a real execution. My point is that for copy jobs: - At the scheduled time, the function do_mac_init chooses the jobid(s) to copy. - At the start time, the function do_mac copies the chosen jobid. Contrast this with verify jobs: - At the scheduled time, the function do_verify_init does not choose the jobid to verify. - At the start time, the function do_verify chooses the jobid to verify. Is this different by design or was it just implemented like that? __Martin _______________________________________________ Bacula-devel mailing list Bacula-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-devel
