From: Zoltan Forray/AC/VCU [mailto:zforray AT VCU DOT EDU] 
> Due to this situation, TSM is fast loosing face as a viable 
> DR tool (eventhough immediate management realized that a lot 
> of the slowdown is the AIX system and the sheer number of files).
> 
> So, where is this leading to.........
> 
> I am looking for help/suggestions/recommendations from other 
> folks who may or may not be using TSM in a DR situation, that 
> has anything even remotely similar to this environment.

Keep in mind that TSM's primary purpose is file backup and restore.
Using it as a DR tool requires a lot of additional thought (and work)
about how you deploy it, and also how you deploy all the other aspects
of DR that are required for a successful recovery. Your failed machine
is a prime example. As a TSM administrator, I would *never*
single-thread any aspect of backup or recovery for a machine as big as
250GB. I would do everything I can to assure a fast recovery--multiple
NICs on the client (and server), tape collocation, use of mulitple
nodenames, multiple SCSI adapters/fiber cards for library connections,
etc.

Realizing that this idea does you no good now, I would still suggest
that you break the use of the TSM client into smaller pieces. Give the
client machine several nodenames, and point each to its own option
file--each of them backing up a portion of the total client data. You
could break 250GB into, say, 5 pieces, each of them 50GB. This would
allow you to more easily multistream large-scale restores, and speed
that puppy up!

And, as I've said on numerous occasions:

Rule #1 of disaster recovery: Practice it before you have to.

--
Mark Stapleton (mark.stapleton AT berbee DOT com)