Hello David, Thanks for your thoughts. I think there are several points that you have minimized or overlooked in your response:
1. Bacula currently permits specifying multiple Media Types in a Pool. 2. Bacula currently permits Storage devices to be specified in the Job resource 3. Bacula currently permits both Pool and Storage overrides in Run resources. None of the above can be removed or changed without causing total disaster to a very large Bacula community. My question was about the order of what takes precedence over what, not in is better or worse than other options. For version 1.39.x, you can run Bacula exactly as you want using Storage resources in Pools and in the Next Pool. Both methodologies cooexist in Bacula (though they probably don't function very well together). See below for more comments ... On Wednesday 22 November 2006 19:35, David Boyes wrote: > > Defining and figuring out what storage device is going to be used has > > become a > > bit too complicated in version 1.39.x. This is mainly due to the fact > > that > > we have two different storage devices for each job and three possible > > places > > to specify them: > > My 2 cents worth: > > This can be simplified dramatically by specifying the Storage resource > only in the Pool definition, and then specifying only the Pool in all > other places. Since (IMHO) pools are highly unlikely to span multiple > SDs, identifying what SD to use is selectable from the devices available > in the Storage resource associated with the pool. Some notes below: Yes agreed. > > > Migration job: > > read storage: job storage resource > > Shouldn't the migration job always be using the Pool resource being > migrated One can do that, but it is not the only way of doing things. The read part remains compatible with the existing code. > and feeding to the NextPool, or overriding the NextPool > resource, not the storage resource? That is how it is done for the writing side. > For migration, we're looking at > volumes in pools, not individual volumes (other than the case where we > have deliberately limited the selection criteria to a specific volume > within a pool via the selection keyword), No, that is not really correct. For migration, as it is currently implemented, we are looking at Jobs. Everything breaks down to a Job. This has certain constraints, but I could see no other way of implementing Migration in the current Bacula otherwise. > so there should be no reason > to specify individual devices for migration jobs. You have to be able to properly get to the original data, and I don't think it would be wise to have one syntax for restores and a different one to find the read side of a Migration. > > > read storage: pool storage resource > > Correct. > > > read storage: run override resource > > See above. Migration is about pools, not devices. No, it is about Jobs, with the caveat that Next Pool does define what set of devices it can be migrated to. > If you need to migrate > to volumes that are not in a pool then you set up a temporary pool and > draw it's volumes from the scratch pool. All Volumes by definition are in one and only one pool, and as I said, we are migrating jobs not volumes and not pools. > > > read storage: command line??? > > Not sure what you mean by this. Sorry that was not very clear. I meant that the read storage could be overriden by the command line (i.e. in manually starting a Migration job), but I was not sure of what order it was applied ... > > > write storage: pool next pool storage resource > > (yea, try to figure out the above in C it is > > job->pool->next_pool->storage > > Correct as I understand the implementation. See comments above. Yes, but it is terribly complicated, and IMO the "average" user doesn't understand Pools so is going to break his brain on this. > > > Backup Job: > > write storage: job storage resource > > See above for discussion of pools. If pools drive the selection of > volumes, the pool definition will clearly define what SD should be used, > unambiguously and consistently across all actions in Bacula. Unfortunately the above, however good it may be, is not compatible with the existing Bacula (if you force it on the user), and probably more than 50% of beginning users will not understand how pools work. Any big enterprise backup expert will, but not the majority of Bacula users, IMO. > > > write storage: pool storage resource > > Ditto. > > > write storage: run override resource > > Ditto. > > > write storage: command line??? > > Not sure again. > > > Restore Job: > > read storage: who knows, probably the same as > > Migration. To be checked. > > In a normal case, the pool definition of the pool containing the volume > should determine the SD to use. This is now possible, but it is not *enforced* so you just need to use a little discipline in writing your .conf file. > In the nasty case of full disaster, you > could temporarily override the pool storage resource from the command > line, but that (in my mind) would be a situation where you are clearly > out of the normal parameters, and are doing it consciously. > > See comments above wrt to Migration. The same cases exist; migration > just makes this problem more visible. Yes, it is all a bit too much complicate. Perhaps over time, I can deprecate features that add to the complexity such as Run overrides, but that is not something that will happen any time soon. Best regards, Kern ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
