While I appreciate the suggestions, the biggest issue is, as always,
$$$$$$$$$$$$$$$$$$$$$$$$$.

Each additional client license costs $5 per month.

I don't have a spare terabyte lying around to do DR testing for 1-server.

Thanks for the suggestions. We will look into the issue of multiple backup
ID/streams, while we are looking into moving this node to an AIX based TSM
server !





"Stapleton, Mark" <stapleto AT BERBEE DOT COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
04/08/2003 08:43 AM
Please respond to "ADSM: Dist Stor Manager"


        To:     ADSM-L AT VM.MARIST DOT EDU
        cc:
        Subject:        Re: Looking for Help/Alternatives/Suggestions/Ideas


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)