Another thing to remember -- If you don't have time to migrate down to 0 on the disk pool every night: when TSM migrates, it takes the LARGEST filespace first, not the OLDEST data. So you can have little bits of old stuff hanging around in the disk pool.
And if you don't have time to migrate all the data every night, another way to protect your data is to go ahead an make your COPYPOOL tape right off the disk pool, instead of waiting until migration happens: BACKUP STGPOOL diskpool copypool Also saves tape mounts! -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Baughman, Ray A. Sent: Wednesday, July 21, 2004 9:46 AM To: [EMAIL PROTECTED] Subject: Re: storage pool raid 1? -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] Behalf Of Stapleton, Mark Sent: Wednesday, July 21, 2004 9:40 AM To: [EMAIL PROTECTED] Subject: Re: storage pool raid 1? From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Sparrman In my experience, I see almost no case for fault tolerance in TSM-based disk systems that normally perform a daily migration to a tape-based primary storage pool. If a system crashing prior to migration worries you, perform your migration as early in the day as you can after clients finish running their backups to a cached disk pool. What would be wrong with running migration during the backup process? I have client backups running around the clock and I also run migration around the clock. I have a lot fewer disk drive than storage pools, so I have a process that runs migration on one disk pool at a time. I've had no issues with performance, but I was wondering if I've overlooked any other got-you's Ray Baughman
