Like the idea of multiple node names per machine. Say we set up
gbnf01c-gbnf01z and let each drive be a "machine" I'm thinking we would
actually get through the backup faster that running it all as one machine.

Curt Magura
Lockheed Martin EIS
Orlando Fla.
321-235-1203


-----Original Message-----
From: Stapleton, Mark [mailto:stapleto AT BERBEE DOT COM]
Sent: Tuesday, April 08, 2003 8:44 AM
To: ADSM-L AT VM.MARIST DOT EDU
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)