On Monday 23 November 2009 16:42:48 Blake Dunlap wrote: > > On Friday 20 November 2009 14:44:54 Martin Simmons wrote: > > > It there a technical reason why the NextPool directive is part of the > > > > pool > > > > > at all? > > > > It was not really a technical reason, but David Boyes suggested doing it > > that > > way, possibly because that is how TSM does it. At the time, I wasn't > > really > > sure if that was the best way, but today, I am sure that it was the best > > way > > to do what we want (good suggestion David) -- see below for why ... > > > > > When I first heard about migration and copy jobs, I expected to > > > find something like a TargetPool directive in the job definition, so > > > > that > > > > > it can be varied for each job. > > > > Although it would slightly facilitate the configuration in a few cases by > > allowing a target pool in the Job, it would have some negative > > consequences, > > namely that if like many users you separate Full, Diff, Inc into separate > > pools, it would vastly complicate configurations -- requiring schedule > > overrides and such. > > > > However, Pool and Storage schedule overrides have turned out to be a real > > pain > > to get right for a number of reasons -- the most obvious is if a job is > > automatically upgraded, in general, the schedule overrides will get > > botched > > up. If I can, I intend to remove Pool and Storage overrides in the > > schedules. > > This would break how we currently accomplish some of our goals (the pool > aspect) > > > I think the best place for the Storage definition (suggested by David) is > > in > > the Pool, and likewise the best place for the output Storage is through > > the > > Next Pool in the Pool definition. Unless I am mistaken, it is just as > > easy > > to change the Pool definition in the Job as it is to change what would be > > Target Pool in the Job. > > > > Anyway, that is how I currently see it. If I could see a real practical > > example why a Target Pool is necessary, I would consider it. > > Being able to do copy/migrate jobs to multiple locations from a single > source, as well as trying to do both copy jobs to one location, and virtual > fulls to another.
I don't understand the above. What is your definition of "locations"? Is it a Storage daemon or a Pool or something else? > > At the moment we work around it by specifying different source pools that > would still contain jobs (as we have different incremental diff and full > pools), but it is somewhat of a hack, and can be fragile. I don't understand the above either. Pools do not contain Jobs. Jobs use Pools. > > Unless I am missing something? I am not sure because I didn't "get" what you wrote above. The problem I have with schedule overrides, particularly for Pools is that they do not take into account the fact that a Job can be automatically upgraded, and thus they do not work. We need to figure out better ways to give flexibility without creating Jobs that can put data into the wrong Pool (or Storage). I don't plan to eliminate any feature until we have a better way to do it. That said, schedule overrides were a very bad idea that did not take into account the complications associated with automatic upgrades, which are a very important feature. Regards, Kern ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Bacula-devel mailing list Bacula-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-devel
