Whoops.....Response below meant to go to an internal address not as a reply
to the list. None the less still like the idea of breaking up some of our
bigger machines into smaller "bite size" chunks.

We also struggle with restore elapsed run times due to the number of objects
much more than the amount of storage involved.

We have already starting using resourceutilization and journaling (on the
backup side). Better but still not good enough.

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


-----Original Message-----
From: Magura, Curtis
Sent: Tuesday, April 08, 2003 8:51 AM
To: 'ADSM: Dist Stor Manager'
Subject: RE: Looking for Help/Alternatives/Suggestions/Ideas

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)