G. Things I would look for. Dont use 127.0.0.1/localhost for TCPserveraddress. This I have found to be slower for TSM backup/restore on some OS's as it is just a test interface. Make sure active virus scanning is turned off. Software based raid will slow things down too.
You indicated that single file restorations are fast, so those things above could affect them as well. But if your single files were small the writing of them could be simply cached. When restoring a huge backupset it will quickly fill up hardware/software write caching and will reveal the true speed of your disk drives. I hope this helps. Giedrius Jankauskas <[EMAIL PROTECTED] To: [EMAIL PROTECTED] CROLINK.LT> cc: Sent by: "ADSM: Dist Subject: Slow backupset restore, a cry for help Stor Manager" <[EMAIL PROTECTED]> 08/17/2004 06:27 AM Please respond to "ADSM: Dist Stor Manager" Hello Gentelmen, I have browsed through forums and newsgroups but failed to find an answer. I have read that backupset generation can be a slow process, however, I am experiencing a slow restore from backupset. The backupset generation takes aproximately 8 (3 lto tapes) hours, however, now I see that the dsmsvc.exe I/O read bytes rate is only 1.5MB/sec . This is unbelievebly slow and I cannot find the reason for this. I have read that the previous versions of TSM client (4.*) had problems with backupset performance, but not the 5.1.* release. What can influence the restore performance so drastically ? Why is reading backupset so much slower than generating one ? Regular file restore/backup to tape functions properly and reaches 15MB/s. I do not expect that with the backupset as there is some information processing going on, but no 1.5MB/s while the cpu is almost idle. Environment : IBM LTO3600 single drive Windows 2003 server TSM Version 5, Release 1, Level 5.0 Both the client and server is located on the same machine and has the library connected via scsi. Please help !!! Desperate.