Hello Phil, wt., 3 gru 2019 o 13:48 Phil Stracchino <ph...@caerllewys.net> napisał(a):
> On 2019-12-03 06:56, Radosław Korzeniewski wrote: > > Hello, > > > > pon., 2 gru 2019 o 20:05 Phil Stracchino <ph...@caerllewys.net > > <mailto:ph...@caerllewys.net>> napisał(a): > > > > It seems to me like this is a bug, and the selection criteria for a > COPY > > job should not be resolved until the COPY job is actually started. > > > > > > Well, I see a contradiction here. You want to order the dinner but you > > will tell what dish you want after a cook start cooking. But what dish > > he should start cooking? So it won't work, IMHO. > > No, Radoslaw, I think you're missing my point. > No. I fully understand your point. > (...) > But its job selection query is run NOW, even though it will be eight > hours before it can actually RUN. Yes, this is how it works. You require additional step which simply does not exist. You have two stages: - job preparation and queue - get job from queue and run None of the jobs it is to copy have > completed yet, so they do not match its selection criteria. > There is no such link between backup and copy jobs build-in Bacula, so you cannot complain. > But it > won't copy them because its selection criteria were evaluated not when > it STARTED, but when it was QUEUED. > You cannot queue a job with unknow criteria. > What I am saying SHOULD happen is that the selection query for a SQL > QUERY selection type should not be evaluated when the job is QUEUED. It > should be evaluated when the job actually STARTS. How you can start a copy job for jobid=10 when you do not know this job id? > And I assert that > evaluating that query when the job gets queued, hours or even possibly > days before the job actually STARTS, is a bug. > It is not a but. You request an impossible scenario. > You say, > "You want to order the dinner but you will tell what dish you want after > a cook start cooking. But what dish he should start cooking?" > > Well, let's look at that another way. The way the selection query is > evaluated NOW, if I want to copy a set of jobs, I cannot SCHEDULE the > copy job until after the set of jobs it is supposed to copy have > finished. There is no any link between jobs already running and your custom copy job selection criteria. How a copy job should know that it should take into account this unrelated jobs? > But I don't know what time the jobs it is to copy will > finish. Perhaps there will be a delay. Perhaps one job will run > slowly. So how can I know what time I can safely schedule the copy job > for? > It is a different story! I'm sorry but what you request is simply unavailable in current job schedule procedures. It is not a situation where it should work as you expect and for some reason it is not. > ...I can't. Because I can't know when the previous jobs will finish, > and Bacula does not wait until the copy job actually STARTS to evaluate > its selection query. > You should start your copy job when all your jobs finish. You can use scripts here. > Do you see the problem? Phil, I know what is your problem very well, but you suggest that: 1. it is the feature which already exist in Bacula 2. this feature does not work and it is a Bug 3. you suggest a fix Which is not true! > The only thing I can do is schedule the archive > copy FAR, FAR out to be certain the jobs it is to copy have finished. > No. You can execute a "control" job which execute script for copy job run. > But then I have a window of vulnerability during which those monthly > full backups have not yet been copied off-system. (I plan eventually to > extend this to at least the weekly Differentials as well.) > This is the main issue with async replication. best regards -- Radosław Korzeniewski rados...@korzeniewski.net
_______________________________________________ Bacula-devel mailing list Bacula-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-devel
