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
