Joshua - The customer site you write about has obviously done little
work to prepare for restorals such as the one they now find
taking so long, as evidenced by the duration and the antique level
of the client they are using. They need to get serious, and not just
bemoan their situation.
I'm not a Netware guy, but looking back in www.adsm.org shows a lot of
complaints about Netware restoral performance, but disappointingly little
real
analysis to help us all perceive just what the problems are, to mutually
help
everyone on the List. Some Netware users report excellent restoral
performance, so site configuration may be a considerable factor. Andy
Raibeck
and others have offered some suggestions in past responses to List
questions.
I've summarized some of it below, but have a look at the list archives for
more detail. There is obviously much analysis that can be done and some
real
opportunities for improvement.
Network restore performance - Make sure your ADSM client
software is
recent! (To take advantage of "No
query restore" et al.)
- Avoid client compression of data.
- If you have a routed network
environment, have this line in
SYS:ETC\TCPIP.CFG :
TcpMSSinternetlimit OFF
- Use TXNBYTELIMIT 25600 in the
DSM.OPT
file, and TXNGROUPMAX 256 in the
ADSM
server options data set.
- Set up a separate disk pool that
does
not migrate to tape, and use DIRMC
to
send directory backups to it.
- Consider using separate management
classes for directories, to
facilitate
parallel restorals.
- And the usual server data storage
considerations (collocation,
etc.).
Data spread out over many tapes
means
many tape mounts and lots of time.
- Consider tracing the client to see
where the time is going:
traceflags INSTR_CLIENT_DETAIL
tracefile somefile.txt
Richard Sims, BU
|
