Back when only one migration process was allowed per pool, having multiple pools allowed for some parallelism.
Ideally the disk storage pools should come out of two different volume groups. That way you can give back all the LUNS that comprise volume group A, while the storage admins do whatever they need to do, and then later on do the same thing with the LUNS for volume group B. I really don't like one big disk storage pool. You can't say much intelligible about how one pool gets used. It is either big enough, or it is not. With several pools, you can monitor percent full/utilized over several days to decide which ones need resizing. (Moving volumes from pool to pool is easy.) Its like a brix cup; if all pools fill at a similar rate, then they are correctly sized. (Oversimplified, I know.) I'm not a big fan of one HUGE disk storage pool either. (A weeks worth for example.) People tend to accept a huge slow pool in liu of a smaller faster pool, and I'd rather have 2-3 days worth of fast disk storage pool than a week's worth of slow pool. (Unless you've neglected your tape environment for years, the difference in restore speed between disk and tape for days 3- 7 shouldn't matter that much.) Also, you don't save any work for the system. Very little will age out of the disk storage pool before needing to be migrated to tape. (Even if you do have a week's worth.) Have you ever moved a waterbed? Big pools are about that much hastle. [RC] From: David McClelland <[email protected]> To: [email protected] Date: 08/04/2010 03:11 PM Subject: Re: [ADSM-L] guide for sizing storage pools Sent by: "ADSM: Dist Stor Manager" <[email protected]> I echo Wanda's points here, expanding that 1) another good reason for having at least an entire night's backup on DISK storage pool is that many of your restore requests may be for data within the last 24-48 hours and may be most quickly serviced by restore from DISK rather than TAPE; 2) one 'good reason' some have chosen in the past to separate storage pools is if they're managing different types of backup/archive data, for example, OS/binaries which are typically pretty small and static, versus SQL Server or Oracle database backups which are typically very large files kept for a set number of days - tape reclamation comes into play here, ensuring you make best usage of your tape volumes, and having these large data types expire at around the same time on the same tape typically can reduce your administrative tape reclamation overhead (cf. wise words along the lines of the best reclamation is that you don't have to do). _______________ David McClelland London, UK -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[email protected]] On Behalf Of Prather, Wanda Sent: 04 August 2010 22:41 To: [email protected] Subject: Re: [ADSM-L] guide for sizing storage pools 1) ROT: If you are planning to back up to disk and migrate to tape, your disk pool should be large enough to hold at least one complete night's backup. (That way if you have tape drive problems in the middle of the night, your backups will continue to run and you can kick the robot in the morning.) 2) One, until you have a really good reason to make more. If you have all your space in 1 pool, TSM can make the most flexible use of it. (If you have it divided into 2 pools, Murphy will insure that one pool will run out of space on the day the other is only 10% used.) An example of needing 2 disk pools: you are creating 2 tape pools, one which will be copied to go offsite and the other not copied to go offsite. If you want to migrate to 2 separate tape pools, you have to start with 2 separate disk pools. Backing up different types of OS, having different domains with different retention times, etc. do not require any type of pool separation. Use 1 as long as you can, let TSM do the work for you.. W -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[email protected]] On Behalf Of Dana Holland Sent: Wednesday, August 04, 2010 5:32 PM To: [email protected] Subject: [ADSM-L] guide for sizing storage pools A typical newbie question, I'm sure - but is there a guide to help determine how to size storage pools? And how many storage pools you should create? I found a Redbook from 2006, but is there anything more recent? __________ Information from ESET NOD32 Antivirus, version of virus signature database 5341 (20100804) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com U.S. BANCORP made the following annotations --------------------------------------------------------------------- Electronic Privacy Notice. This e-mail, and any attachments, contains information that is, or may be, covered by electronic communications privacy laws, and is also confidential and proprietary in nature. If you are not the intended recipient, please be advised that you are legally prohibited from retaining, using, copying, distributing, or otherwise disclosing this information in any manner. Instead, please reply to the sender that you have received this communication in error, and then immediately delete it. Thank you in advance for your cooperation. ---------------------------------------------------------------------
