FWIW, here's the characteristics we use to split up our storage pools: * Backup vs archive - we segregate archives from backups since their retention (and subsequent reclamation) is so much longer than backups
* Library - obviously we need to have separate storage pool hierarchies for separate libraries * Simultaneous copy - some of our clients are so slow that they can't make effective use of simultaneous copy, so we have a separate hierarchy on one server for those systems that does not do simultaneous copy. I guess in my mind a file from Windows is no different than a file from UNIX, so it doesn't make sense to segregate storage based on source platform. -- Skylar Thompson (skyl...@u.washington.edu) -- Genome Sciences Department, System Administrator -- Foege Building S046, (206)-685-7354 -- University of Washington School of Medicine On 05/08/13 12:43, Rick Adamson wrote: > Hi Wanda, > Note that in my situation not only were domains combined, but also storage > pools. > Combining the domains resulted in more clients utilizing the same disk, > primary, and copy pools, which ultimately increased the time needed to > migrate, backup, and reclaim specific pools. The end result was the need to > revisit my admin task scheduling and in some cases disk pool sizes. > > Obviously, this may not be an issue for admins who use a single storage pool > structure for multiple domains but many systems I have run into have storage > pools dedicated by platform (following their domain model). > So I just thought it worth mentioning.... > ~Rick
