> I did not always do that, but I learned that the flexibility of pools > across different storage devices and media types is less valuable than a > simple setup.
Multi-type pools also make backup and storage management policy almost impossible to implement. If we define a pool as an administrative group of volumes with a certain set of behavior characteristics (eg, similar media type, physical location, capability (size of volume, etc), handling characteristics, etc) it's a lot clearer what's happening. Wildly different media types and characteristics in the same entity are both confusing and almost impossible to schedule. There's also the operator characteristics. If this were z/OS or some other operating system with a common media mount capability, then it wouldn't be a big deal, but the current approach really makes it hard, esp for wildly different media types. Pre-migration, the mixed pools made sense in that you could copy data from volume to volume by specifying the right options and you did all the footwork of keeping track of the devices manually. Now, post-migration, that's bad behavior. Bacula should be in control of device selection and usage regardless of what data is involved, and to do that, the selection process needs to be clear in terms of what volume, with what capability do we need to select, and where should it be processed. If pools are clear that "this volume in Pool X is associated with this SD" then the rest of the selection parts fall into line pretty quickly. The side effect is that if you are sharing drives with other applications (this means when you change magazines, etc too, Arno...8-)), then you have to start taking the drive offline to Bacula before you snitch it for some other purpose. This is a bit more discipline that some shops have at the moment, but it also results in a much more predictable behavior. > The only exception, in my opinion, would be to define the storage on the > command line - that should alwys have the highest priority. It would > allow to create pools across different storage devices, but in case of > serious problems or during emergency restores this might be helpful. I'd even go further and argue that the only place that this makes sense is in a restore when the entire bacula infrastructure has been destroyed (eg in brestore). Normal Bacula shouldn't permit specifying devices; that's a big part of the value of the Bacula engine -- it manages all that stuff. The key item for that would be to provide the ability to disable a device (in case it's broken, has a stuck tape, etc) and take it out of the device selection process w/o removing it from the configuration file. > Finally, it's not a fault to allow users to shoot themselves in the leg > - as long as there are enough warnings :-) See above. The only place where this makes sense IMHO is in the case of total destruction of the Bacula infrastructure. At that point, you don't have any choice but to permit it (and in fact, you have to require it to get the necessary info to do the restores). ------------------------------------------------------------------------- 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
