>> On Wed, 11 Jan 2006 18:11:13 -0500, Jim Zajkowski <jamesez AT UMICH DOT EDU> 
>> said:


> I'm working on our internal "late night admin guide," and one of the
> things I'm thinking of is how can I get TSM prepared to do a restore.

> Here's what I mean: let's say I know that there is going to be some
> filesystem maintenance on a client.  Since we've been burned by that
> kind of operation in the past, I'd like TSM to prefetch the
> appropriate data from tape and have it ready to go (on disk) for a
> restore.

[ ... ]

> Am I out of my tree?  Do people do this?

I don't have a tree, so I can't help you there.  But I do MOVE
NODEDATA when I'm anticipating a restore.  This can sometime waste
some space in the moved-to place (because it moves inactive data too)
but especially if you haven't been collocating it can make a huge
difference in the customer-perceived response time.

You can also more-easily use N tape devices to get at the data,
without the client-side bottleneck for saving it.  As we've observed
here in the past, the TSM servers' IO is usually way out ahead of any
clients', so if you can keep the server busy for an hour reading and
mounting tapes, it may save many times that client-side.

I'd say make sure that you pre-stage the data to a different storage
pool than your usual landing pad, if you can possibly find the space.
You could fill up the landing pad, and have it start migration, and be
chasing your tail for quite a bit.

Further, you may want to keep the data on disk for more than one
( night / day / backup cycle ), in which case you'd be geting in your
own way.



- Allen S. Rout