On Wed, 13 Dec 2006, Arno Lehmann wrote:

> Hi,
>
> On 12/13/2006 1:07 PM, Alan Brown wrote:
>> Can anyone else confirm this?
>>
>> ====
>>
>> Rerun Failed Levels = yes
>>
>> If an incremental job is scheduled to start before a full or differential
>> job has completed (ie, still running): When the incremental job starts the
>> previous (still running) job is detected as "failed" and the incremental
>> is upgraded to full or differential.
>>
>> ====
>>
>> It seems repeatable here but I'd like confirmation from someone else
>> before filing it as a genuine bug.
>
> I think that's the behaviour, right.
>
> One of the reasons why I prefer to have 'maximum concurrent jobs=1' in
> my job definitions. (And a max wait time, too, so even under dificult
> conditions the job is not started too in a row.)

I do have max concurrent jobs=1 and a 22 hour max wait.

> I'm also not sure how to prevent this. The key question is which job the
>  incremental one should be based upon. If you take the last job before
> the currently running one, that looks like a safe choice, and could
> probably implemented by slightly modifying the SQL query for the latest job.

The problem is that it seems to take status R as "failed" instead of only 
going on on status "f"

The result was that I had 3-4 500Gb+ full backups in a row before I 
noticed this behaviour

I appreciate the issue with where incrementals should key off, but as far 
as I can see it shouldn't be happening with max concurrent jobs = 1

AB

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Reply via email to