Hi Arno, On Thursday 20 September 2007 03:11:45 am Arno Lehmann wrote: > Hi, > > 20.09.2007 08:42,, Ivan Adzhubey wrote:: > > Hi, > > > > Actually, my question is how does Bacula work with Rerun Failed Levels > > option disabled? I have it enabled for all jobs and never tried running > > backups without this setting so I have no experience. When enabled, if > > previous higher level backup is not found in the catalog then current > > Incremental backup is upgraded to Full. But what happens if Rerun Failed > > Levels = no and no previous Full backup is present at all? Will > > Incremental be still upgraded to Full? > > Yes. > > > That's what I suppose since obviously there would be no file set to > > compare against anyway. Please, correct me if I'm wrong. > > No reason to correct you... > > If "rerun failed levels" is set, Bacula checks if after the latest > succesful backup there were jobs with a "higher" level than the > currently running one, and upgrades the currently running job to that > level.
The reason I'm asking is the problem I've encountered today. I am still waiting for the second tape drive to arrive and meanwhile the amount of data on our servers has grown to a level which our single AIT-3 drive can hardly handle. As a result, for some of the largest backups daily cycles started to overlap. In addition, I noticed that even with the successful full backups already available, next scheduled incrementals are still elevated to full! As a result, the whole system got stuck into an endless loop of full backups waisting large number of tapes. I have set Max Start Delay = 20 hours to prevent overdue backups from sitting in the queue long enough so they overlap with the same (incremental) job scheduled next day, hope this will help. But I still don't understand why it happens. It looks like even though the decision to upgrade (or not) backup level is taken only later when it is dispatched to run, previous job search at that point only looks for jobs that were available at the time job being dispatched was originally scheduled, not at all of the jobs that are already present at the time it is dispatched to run (which in my case can be 24-48 hours later). This may seem a reasonable algorithm but I'd love to see an option to override it. Anyway, my setup is far from optimal at the moment and this is by no means a Bacula fault. Good stress test however... --Ivan ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
