On Monday 12 June 2006 14:29, Arno Lehmann wrote: > Hi, > > On 6/8/2006 10:08 AM, Chris Crowther wrote: > > Hi All, > > > > I seem to have run across a problem when storing Full and > > Differential backups on tape and Incrementals on disk, when combined > > with re-running missed levels. > > Ah yes. I knew what you was aiming at at this point :-( > > > If Bacula upgrades the job to either Full or Differential from an > > Incremental, because of a missed job, it tries to use the wrong > > storage device, ie it uses the File one that it would have been > > using for the Incremental job. > > > > It does change the Pool to the correct one, probably because I've > > told the Job which Pools are used for Full and Differential. On a > > normal scheduled backup, without any problems, the storage is > > overriden within the Schedule (multiple jobs use the tape library > > for their Full and Differentials, but there's several Pools, so I > > set which Pool a job should be using in the Job then just modify the > > storage in the schedule). > > > > Is it the case that you can't combine the two; or if you do you have > > to put up with a Full backup going to where an Incremental would? > > Yes and yes ;-) > > Depending on what you want. > > Admittedly, the best solution would be 'Full Backup Storage=', > 'Differential Backup storage=' and 'Incremental Backup Storage=' > directives in the job resource.
I think Pool Storage directives are probably better because they slow down the proliferation of Bacula directives, and hopefully give the same thing in a better way without using Run overrides. :-) > > In the long term, I'd like to see the ability to change the job setup > dynamically using python events. > > As of now, I decided to go the manual way: I create volumes manually (I > don't use file storage) and, when a job level is automatically elevated, > I usually notice the stuck backup job in reasonable time and manually > cancel that job and re-run the job with the necessary settings by hand. > > I wouldn't do this at customer sites, though, where there's noone around > who could handle that. > > Arno > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Bacula-users mailing list > > Bacula-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/bacula-users -- Best regards, Kern ("> /\ V_V _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
