MTU=Maximum Transmission Unit
and is a parameter of the network card/driver.
"Kamp, Bruce" <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
09/23/2003 04:43 PM
Please respond to "ADSM: Dist Stor Manager"
To: [EMAIL PROTECTED]
cc:
Fax to:
Subject: Re: Very long Netware restore
I don't the exactly what MTU means.... Basicly it is the packet size. We
found this out after my network guys ran Sniffer on our network. The
difference in restore tmes was 2-3 days to about 10-12 hours! Your
network
people should be able to give a better definition! I colocated my
tapepool
after my first big reatore.
---------------------------------------
Bruce Kamp
Midrange Systems Analyst II
Memorial Healthcare System
E-mail: [EMAIL PROTECTED]
Phone: (954) 987-2020 x4597
Fax: (954) 985-1404
---------------------------------------
-----Original Message-----
From: William Rosette [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 23, 2003 3:35 PM
To: [EMAIL PROTECTED]
Hey Bruce,
I had a similar problem with 500 GB of info on 2 clients of
Novell/Netware, 1 200 GB and the other 300 GB. It also took days. I was
told to collocate and restore the dirs only first. What does MTU stand
for?
Is it a TSM client setting?, server setting? or Novell/Netware setting?
Thank You,
Bill Rosette
Data Center/IS/Papa Johns International
WWJD
"Kamp, Bruce"
<[EMAIL PROTECTED]> To:
[EMAIL PROTECTED]
Sent by: "ADSM: cc:
Dist Stor Subject: Re: Very long
Netware restore
Manager"
<[EMAIL PROTECTED]
.EDU>
09/23/2003 03:19
PM
Please respond to
"ADSM: Dist Stor
Manager"
Had this problem before! It was an MTU size problem. Once that was fixed
the restore flew!
--------------------------------------
Bruce Kamp
Midrange Systems Analyst II
Memorial Healthcare System
E: [EMAIL PROTECTED]
P: (954) 987-2020 x4597
F: (954) 985-1404
---------------------------------------
-----Original Message-----
From: Richard Rhodes [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 23, 2003 2:07 PM
To: [EMAIL PROTECTED]
We recently did a full restore of a Netware server. Basically, we're
interested if the restore time sounds reasonable - it doesn't to us.
The server that was restored is actually at a remote site from the TSM
server location, but the restore was done at the TSM site, then, driven to
the remote site for installation.
The restore specs read like this:
Compression: Files compressed using TSM client compression
Size: 240gb
Files: 938,617
Restore Time: 50 hours
Throughput: around 1.3mb/s average speed (240gb/50hr)
Network: 100MB/fdx, local to TSM server
(admins checked for duplex mismatch)
Tape Drives: IBM 3590
Netware Server
Version: NW5.1 SP3
Dell 2650
1 - 2ghz xeon processor
2gb memory
513mb cache on processor
This just doesn't sound right. After this was all done, we created a
backupset to see just how fast TSM could access the servers files.
Backupset Creation Time: 11 hours
From Tape Drive: IBM 3590
To Tape Drive: IBM 3590
So . . . . the bottleneck doesn't appear to be the TSM server.
Any thoughts as to why our restore took 50 hours??? The obvious answer is
that the files had to be uncompressed on the client, but I would have
thought a 2ghz processor would be able to uncompress much more than a
1.3mb/s data stream.
Thanks
Rick
-----------------------------------------
The information contained in this message is intended only for the
personal
and confidential use of the recipient(s) named above. If the reader of
this
message is not the intended recipient or an agent responsible for
delivering
it to the intended recipient, you are hereby notified that you have
received
this document in error and that any review, dissemination, distribution,
or
copying of this message is strictly prohibited. If you have received this
communication in error, please notify us immediately, and delete the
original message.
