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