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
> >     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
Bacula-devel mailing list

Reply via email to