Something easy to check would be the client's network interface. If it
is attached to a fast-ethernet switch, make sure both the client [and
perhaps the server] and switch are set to 100 full-duplex and not
autonegotiate. Use smitty chgenet, select the interface and set/check
the setting [media setting].
Mahesh
>>> Aaron.Hicks AT INTERTRADE DOT COM 03/27/03 02:57PM >>>
Hi,
I don't post much to this list but I have been following for about a
year
or so now. I know this has been discussed before but I have looked
through
the archives and found nothing that would explain the length of time it
has
taken so far to restore 8.2 G of data files which are all on the small
side,
approximately 16K per file. I know that this is 512,948 files, but it
has
been running for 48 hours now and has only restored 1G of data. Now
here a
some of the specifics of the set up here.
TSM server:
IBM B50 running AIX 4.3.3.9
TSM Server Version 4, Release 1, Level 4.0
LIB 3581 with 1 drive
TSM Client:
IBM B50 running AIX 4.3.3.9
TSM Version 4, Release 2, Level 0.0
What we are doing may be strange, but here it is. We have the tapes
from
our production nfs server. Which were backed up on the following
backup set
up:
TSM server:
IBM B80 running AIX 4.3.3.9
TSM Server Version 4, Release 1, Level 4.0
LIB IBM 3583 with 3 drives
TSM Client:
IBM B50 running AIX 4.3.3.9
TSM Version 4, Release 2, Level 0.0
We went through the disaster recovery procedure using the
RECOVERY.SCRIPT.DISASTER.RECOVERY.MODE that was created the drm. We
then
loaded all the tape we could in the 3581, 7 in at a time, and started
a
restore the /export/home disk using the following commands:
dsmc -virtualnodename=spock
tsm> restore /export/home/ec01/ITSF_FILE_ROOT/* -sub=y -replace=y
-ifnewer
I have had to restart this restore twice due to it dieing. I have
been
running dsmadmc -CONSOLE on the server and see no errors when restore
stops
on the client. Nor are there any error in the activity logs. Sorry
for
going on so long but I figure you might need all this info, than again
maybe
not:).
Thanks to all
Aaron Hicks
Unix Administrator
Dynec
Campbell, CA.
|
