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:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Baughman, Ray A.
Sent: Wednesday, July 21, 2004 9:46 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: storage pool raid 1?


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]On Behalf Of
Stapleton, Mark
Sent: Wednesday, July 21, 2004 9:40 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: storage pool raid 1?


From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] 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