Matthew,

Look into TSM release 4.2.2.13. One of the fixes in this release was for
this problem. We sat in on an IBM CritSit for this problem until this was
written.

Not sure if it will help but here is my experience from this issue. The
amount of files, size and directory structure play a huge part in the
restore. Many smaller files in deep directory layers will be very slow.
There is no table of contents for backupsets. The complete tape or set has
to be read for each restore or query, this is why a QUERY BACKUPSETCONTENTS
takes almost as long as an actual restore.

If you can find someone knowledgeable at IBM about release 4.2.2.13, it may
be some help.

You can contact me directly and I will give you the contact list level 2
guys at IBM that sat on our CritSit. I know how you feel, in some situations
a backupset is the only answer for a specific need and the restore is a big
part of that.

Mark Bertrand


-----Original Message-----
From: Matthew Glanville [mailto:matthew.glanville AT KODAK DOT COM]
Sent: Tuesday, August 17, 2004 1:42 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Slow backupset restore, a cry for help


> The problem lies within the server side, since it does send the data to
the client very
slowly (and from the task manager I can see that the tsm server process
is reading data slowly as hell).

Wont that speed you see will just adjust itself to what the client can
write to the disk?
Most of the performance problems I have seen can be tracked down to network
problems or disk write speed problems caused by anti-virus software or
software raid, be sure you take care of them first.
Test the writing to that disk and TCP transfer rates by using somthing
else, ftp for instance, just to be sure it is or is not TSM client/server
issue.

> There are lots of small files, but could that be the problem ?

Yes, from my experience the more individual files you have the longer
everything takes, regardless of the amount of data.  It isn't necesarily
TSM, but the underlying file system.  Logging will slow it down a bit more
too.  Even the layout of the files in the directory can have an effect, are
there 10 million in one directory?  I've seen that before it ain't pretty.

So just how many files are there?

> How can I find out what the bottleneck is ?

  Keep looking, at more than just I/O speeds.  memory use is another place
things can slow down, is there alot of memory paging/swapping to disk going
on?  Lots of performance problems can be tracked down to this issue.

>As I have mentioned before - speed of generating backupset, regular
>backups and regular restores is normal (10-15MB/s) for an LTO drive.

This is why I believe the problem has to do with somthing on the TSM client
side and what it is doing.  Thats the one thing that's being introduced in
the equation when restoring a backup set.

> Frustrating.

This probably means the answer is somthing simple.

Hey, are you recovering the backup set using the GUI and a dialup link
through a remote access tool?  This can slow down restorations too...  use
the command line at all times unless on the console.  Even then, command
line is slightly quicker.

Matt G.