Hi Everyone, thanks for sharing your thoughts !!!

Richard : you're right, I should have included the commands I used for
restore. But since I tried using them all it was only natural that I
forgot to mention that. I did try the GUI to restore all contents of the
backupset. Seeing that the speed is awful I decided to use the command
line interface and used the following command : restore backupset
bset-name \\server\c$\* z:\ -subdir=yes . It restored several files from
the (beginning of) first tape (3mb total :)) so I know the wildcards are
correct. I though that scanning through the tape (command line case,
where I restore just the needed files) would be faster than restoring
all files with the GUI, but I was wrong. Seeking to the next file and
checking if its name fits wildcards take just as much time as restoring
it, and with the current speed it would take n days.

Charles : there is no antivirus software on the server. Both the client
and the server applications are installed on the same machine. I also
tried restoring the backupset from a client on a different computer with
the same (bad) results. This low speed is experienced only when
restoring backupsets, simply restoring the backed up files works at
normal speed, therefore it probably is not the network interface.

Matthew : it's true that the slow client side would slow down the amount
of data the server transfers, but it's probably not the case. I double
checked and as I've mentioned the raid system easily deals with 20mb/s.
The client hasn't received any new information in 10 hours, which,
keeping in mind that the first tape is still mounted, means that the
server didn't find any data matching wildcards in that time. 1 tape -
more than 10 hours. The total number of objects writtent to the
backupset in question is approx. 1.5 million (spreaded through
directories), for today's modern times I think that's not much... There
is also plenty of memory available and other resources available, also
seeing that regular restores perform as expected I doubt that it's
resouce problem :(

Mark : while searching forums I found that the tsm 4.something version
had that problem but since I am using 5.1. I though the problem has been
dealt with so I was looking for other clues. I can understand that
restoring/seeking through large number of small files can be slower, but
the tape drive doesn't use even 1/10 of its reading speed while the cpu
is almost idle. I though that after going through the filespace with the
small files the restore process will speed up, but with 1.5mb/s and less
I was not able to check that theory since the restore process having
plenty of time hasn't walked through a single tape yet. ;( Now I cannot
cancel the restore without any firm information :) since I've invested
much time in it and restarting it will cause it having to seek through
the data again.

Please, if you have any ideas do not hasitate writing them to me :)


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Richard Sims
Sent: Tuesday, August 17, 2004 8:54 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Slow backupset restore, a cry for help


>...I am experiencing a slow restore from backupset...

Please... When posting questions regarding restorals, please include the
command line(s) or GUI operation you are using, as the particulars of
the operation may make a huge difference, as IBM article swg21156683
illustrates in a Unix environment, using wildcards (and, by
extrapolation, in any environment where a restoral is being performed
via multiple individual commands). Seeing the manner in which the
restoral was requested of TSM will help us to better ponder the
circumstances.  We can't promise to have the answer solely on that
basis, but it will give us a better shot at it.

   thanks,  Richard Sims