Hi, 20.09.2007 09:37,, Ivan Adzhubey wrote:: > 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.
Well, that is a bad situation, right. As far as I know, there is some thought invested in fixing that eventually, but that won't help you now... > 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, As far as I know, the moment the dicisoion to upgrade takes place is when the job starts running, i.e. the scheduler fires it off. > 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. Actually, I'm not sure if this is a reasonable behaviour, just because of the sort of problems you encounter (by the way, I see the same here in my office...) > > Anyway, my setup is far from optimal at the moment and this is by no means a > Bacula fault. Good stress test however... Right. By the way: My work-around for a limited time would be to disable the jobs that run too long and only enable them when the regular full backup is run. That has the side-effect of not running backups on one day, but the value of having an incremental done while the full backup still runs is doubtful IMO. You could even do that more or less automatically, I guess: Use arun before command that issues the necessary disable command to bconsole, and in a run after job command, send an enable command. Untested, but might be worth a try. Alternatively, you could use a run before job script that checks if a job of the same name is already running and return with a result code of 1 so the job is failed. I hope that the level the job is at then is still not elevated, so the failed job would be of level incremental - if it is already at level full, that wouldn't help... Better, of course, is to have the hardware so that your scheduled jobs can run inside one day, of course. So have fun playing with Bacula until the new drive arrives :-) Arno > --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 -- Arno Lehmann IT-Service Lehmann www.its-lehmann.de ------------------------------------------------------------------------- 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
