On 22 Oct 2001, at 15:48, John Naylor wrote:
> Because you produced your backupset in 3 hours does not mean you will
> get it back in 3 hours. The backupset speed is determined by how fast your 
> host
> server
> can pull the entries from the database and write to its tapes  These speeds 
> are
> likely to be different from how fast your netware server can pull the data in
> and write to its drives.

Exactly what I was thinking when we created the backup set.  I was
looking for a way to take the netware server out of the picture and
get some idea of how fast the TSM server can serve up the files.  The
backup set writes (restores) to a very fast tape (3590E in my case).
In doing so it copies all current versions for of the client, just
like a full restore to the client system itself (our netware server).

If the TSM server can create a backup set in 3 hours, then that's how
fast the tsm server can serve up the files.  It in no way implies how
fast a client can get the file or write the files to disk.  So, if an
actual restore takes 8 hours and a backup set creation takes only 3
hours, then the difference is outside the TSM server - the network or
the client netware server.

In other words, I want to tell our netware admins that the bottleneck
is on their side or in the network.

What would be neat would be the ability to create a backup set to
/dev/null, and truly see how fast TSM can serve up the files.

Thanks

Rick