Somebody do the math here: how long would it take to restore 60 GB from a
directly attached tape drive?
Best case: assume 8 MB/sec, the restore should take a little over two hours.
How many of us have seen that happen? None.
So the rest if overhead setting up to read a file from tape and to set up
the filesystem to lay down the restored file. I would think those two
things will be pretty consistent no matter whose tool is used. Tapes with
better start/stop performance will have shorter read setup times and some
filesystems will be better than others, but the things that need to happen
are the same.
We need some real numbers here.
Kelly J. Lipp
Storage Solutions Specialists, Inc.
PO Box 51313
Colorado Springs CO 80949-1313
(719) 531-5926
Fax: (719) 260-5991
Email: [EMAIL PROTECTED]
www.storsol.com
www.storserver.com
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of
Kronstadt, Dan
Sent: Wednesday, September 20, 2000 6:42 PM
To: [EMAIL PROTECTED]
Subject: Re: Slow restore for large NT client outcome
I think we need the answers to Kelly Lipp's question - how fast is Arcserve
really? But IF it is better, then I dont think we can get away with saying -
its too many files, its NTFS that slows down TSM, etc. Those are the
realities of our servers, and we need a RESTORE (notice I did not say
backup) solution that isn't career ending. Now there was one response that
said thay are MOVING towards mirroring - better late than never - and
another response that said management doesn't like incremental forever -
they need to get over that. All in all, TSM is great - but if any restore
takes 48 hours - WB will be looking for a new tech support manager.
Dan Kronstadt
Warner Bros.
"Who the hell wants to hear actors talk?"
- H. M. Warner (1881-1958), founder of Warner Bros., in 1927
-----Original Message-----
From: Richard Sims [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, September 20, 2000 12:56 PM
To: [EMAIL PROTECTED]
Subject: Re: Slow restore for large NT client outcome
Jeff - I more than sympathize with your predicament as a storage
administrator dealing with NT systems and their administrators.
But be careful about going after a vendor to fix a problem you perceive
to be with their product without first establishing baseline values for
your configuration and otherwise analyzing it determine just where and
what the problem is.
Nick's posting today about NTFS performance and recommendations last
week regarding FTP baseline tests regarding your problem will help to
define it. Such measures will help you obtain baseline values, as close
as possible to optimal values, against which you can compare performance
with more involved applications like TSM, on top of that amalgam.
Being a long-time ADSM guy I'm sure you remember back to postings
where people would wail on IBM about poor performance backing up and
restoring, asking "What's wrong with ADSM???" - when their implementation
choices resulted in 20,000 or more files in one directory, which is
deadly for anything entering such a directory. That is to say, the way
in which systems are configured and implemented, plus networking problems
and operating system defects and design shortcomings can thwart performance
in
any package implemented on them. Some customers unknowingly implement tape
technologies with poor start-stop performance, see slow restoral
performance,
and then blame the restoral software. We have to be aware of what these
things can do to and for us. Know thy technologies, lest they bite thee.
It's a classic situation in data processing that users blame performance
problems on the first thing between them and the computer system, but of
course that's just convenient blame assignment. After all - they have to
blame someone or something, and that's the one thing they know. This is not
to say that TSM is perfect or necessarily blameless in this situation. But
as
customer technicians it's our responsibility to determine where the problem
lies. And for that to succeed the various experts in the environment
(networking, opsys, application) have to work together to analyze it.
Your NT people say that TSM seems like a UNIX product trying to make it
in
the NT space. The irony is that it's a mainframe product that did even
better
in a Unix environment because of that environment's minimized overhead. You
have the unenviable situation of an MVS server and NT clients, with a
lineage
and history of TCP/IP performance shortcomings, high overhead, and file
system
inefficiencies. Your shop is looking at an AIX-based TSM server system,
which
is a good move. Whether "TSM can make it in the NT space" is more up to NT
than TSM: if Microsoft wants to be a serious contender, they have to make
Windows a serious operating system. Many shops won't implement NTs as
enterprise servers because their performance is ridiculously inferior.
Tivoli
gets blamed for numerous things not its fault, like its TDP being unable to
restore individual mail boxes in a certain vendor mail system, when that
other
vendor fails to provide an API to make it possible. Certainly Tivoli would
agree that they should take responsibility for their own failings, but we
should be careful to attribute to them what is actually theirs.
The situation you're in is the familiar one so many of us find ourselves
in, having to address complaints about why things are so bad, when we don't
have measurements to know how much that deviates from how good they can be.
I strongly encourage everyone to get such numbers during off-peak times so
that you have something to compare against, in each area (disk activity,
tape
throughput, tape search time, network capacity, CPU load capability, etc.).
From what you describe, your shop is undergoing an unusual number of
full
file system recoveries. With the size of today's disks and the need for
data
to be current, I would very much avoid dependence on any backup package for
such recoveries. I would recommend some form of disk mirroring for
first-level recovery, to render recovery immediate and current. Rely upon a
package such as TSM for second-tier recovery when the mirror can't do it,
and
for the spot restoral of individual files.
In summary, get those baseline numbers and use them to help isolate the
problem areas. Identifying problems is 90% of their solution. And stay a
huge fan of the product. :-)
Richard Sims, BU
