On Tuesday 24 November 2009 22:15:35 Martin Simmons wrote: > >>>>> On Sun, 22 Nov 2009 12:16:33 +0100, Kern Sibbald said: > > > > 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. > > OK, that makes sense. > > > 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. > > > > 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. > > Yes, it is easy to change the Pool in the Job definition, but it seems > rather hackish to have dummy Pool definitions just so they can contain the > desired Next Pool.
I completely agree, but I haven't yet see a nice overall solution. > > > 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. > > Maybe Migrate and Copy have slightly different requirements? Or perhaps > the current design is targeted at scheduled migration and copying, whereas > some people want to use it for ad hoc copying? Yes, they were both definitely targeted at scheduled job. For ad hoc stuff, I think someone should suggest a run command nextpool override or something like that. Those kinds of additions don't ususally create too many problems aside from the problem of making sure command overrides always work ... > > Here is an example: suppose you want to make regular backups of all data > for disaster recovery, but also copy some of the jobs to special archive > pools. There might be a regulatory requirement to archive emails plus a > security requirement to archive traffic logs. The current design makes it > difficut to use a single pool for the disaster recovery backups. I am open to suggestions (provided they don't created more problems long term). Regards, Kern > > > One thing that a lot of users may not know is that the Next Pool can > > point to the current Pool. In the original Migrate implementation this > > could cause a deadlock reading and writing on the same Volume, but in > > currently released versions, regardless of the Pool specification and the > > Next Pool specification is, Bacula should never attempt to read and write > > on the same Volume. If it does, then I would like to hear about it since > > I consider that a bug (actually it will be some race condition I didn't > > foresee in the code). > > Yes, that's nice. > > __Martin > > > Kern > > > > > Someone already had to hack around this with a dummy pool definition: > > > > > > http://thread.gmane.org/gmane.comp.sysutils.backup.bacula.devel/14084 > > > > > > __Martin > > > > > > >>>>> On Fri, 20 Nov 2009 13:45:06 +0100 (CET), Kern Sibbald said: > > > > > > > > Hello, > > > > > > > > If the only reason is to prevent a deadlock then this override is not > > > > necessary since Bacula (at some version, I think it was 2.4.0) will > > > > not use the same volume for reading and writing. > > > > > > > > If there is some other good reason, please remove the comments about > > > > deadlock and resubmit, and I think you can remove any workarounds you > > > > implemented to prevent deadlocks. > > > > > > > > Kern > > > > > > > > > Item ?: Allow Schedule Resource to override NextPool > > > > > > > > > > Date: 18 November 2009 > > > > > > > > > > Origin: Jim Barber. [email protected] > > > > > > > > > > Status: New request > > > > > > > > > > What: Allow the Schedule resource to define a NextPool= statement > > > > > to override the NextPool statement of the pool defined in the > > > > > job. > > > > > > > > > > Why: I have an incremental pool that each week gets consolidated > > > > > into a full pool via a VirtualFull job. The NextPool directive of > > > > > the incremental pool defines the location of the full pool. > > > > > > > > > > The following week, the next VirtualFull backup will run. It > > > > > will > > > > > read the previous full backups and incremental backups since > > > > > then, > > > > > to create new full backups. It is important that the VirtualFull > > > > > backup does not try to write to the same tape that the previous > > > > > weeks full backup wrote to and left in Append status. Otherwise > > > > > you could end up with the one tape trying to be read and written > > > > > and dead-lock. > > > > > > > > > > At the moment I have a hack to get around this. An Admin job > > > > > calls > > > > > an external command that runs a SQL update to find any tapes in > > > > > the full pool with an APPEND status and change it to USED. This > > > > > runs after the full backups have been done. > > > > > > > > > > Instead I'd like to create two full pools. One for even weeks > > > > > and > > > > > one for odd weeks of the year. That way, even week virtual full > > > > > backups could consolidate odd week virtual full backups with the > > > > > latest incremental backups. And the odd week virtual full > > > > > backups > > > > > could consolidate the even week full backups with the latest > > > > > incremental backups. > > > > > > > > > > The trouble is that the Incremental pool can only define one > > > > > Next > > > > > Pool. I can't have it toggle the Next Pool directive from odd to > > > > > even, week to week. Unless I could override it from the > > > > > schedule. > > > > > > > > > > Doing that would mean I could ditch my SQL hack to manipulate > > > > > the > > > > > tape status. It will also be less wasteful of tapes, since I > > > > > won't > > > > > have partially filled USED tapes throughout my library. > > > > > > > > > > There are possibly many uses for such an override that I haven't > > > > > thought about. > > > > > > > > > > ------------------------------------------------------------------- > > > > >---- ------- 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 > > > > > [email protected] > > > > > https://lists.sourceforge.net/lists/listinfo/bacula-devel > > > > > > > > Best 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 > > > > [email protected] > > > > https://lists.sourceforge.net/lists/listinfo/bacula-devel > > > > > > ----------------------------------------------------------------------- > > >---- --- 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 > > > [email protected] > > > https://lists.sourceforge.net/lists/listinfo/bacula-devel ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-devel
