Any suggestions or ideas?

Sorry to say, but I believe the restore process is tied with the media server's timeout setting and you're stuck changing it, if only temporarily.

This is an older TechNote, but I think what's described still applies to 6.x:

DOCUMENTATION: Where to set CLIENT_READ_TIMEOUT for restores of large Microsoft SQL databases

 http://support.veritas.com/docs/234820

Chris,

Thanks for the reply.  In the MS SQL Server System Administrator's Guide for NetBackup 6.0 on page 189, it reads:

"The timeout problem can be resolved by increasing the NetBackup Client Read Timeout setting. Use the NetBackup Administration Console on the server to change the properties of each client that contains a database you may need to restore. The default for the Client Read Timeout setting is 300 seconds (5 minutes). If you have clients which contain large SQL Server databases, you may need to set this value much higher".

Could this then be considered a "bug".  If so, has it been fixed in another MP.

Many Thanks,

Ron,

Good catch.  I think you've found a bug in our documentation, though.  There is similar language in the 5.1 guide and the 5.0 guide (and it looks we even reprinted it verbatim as TechNote 237780) but we also say that the information in TechNote 234820 applies to 5.x - they can't both be correct.  Looking through some past cases, the timeout definitely looks to have always come from the media server, and support has always recommended changing it on the media server to get long SQL restores to work.  And as you said earlier, it appears that that's what's happening in your environment as well.

Now, having SAID all that, I won't hesitate to waffle - you could certainly press the issue by raising a case with Tech Support and asking for a database expert who could give you a definitive answer as to whether or not this is a bug that could/should be fixed.  Even if all they do is repeat what I've said and then direct you to log an enhancement request, we should definitely get an Etrack created with the TechPubs folks to resolve the documentation conflict.

Chris,

Many thanks on the response.  While I am on a roll, again back to the documentation on Page 189, it reads:

"For example, if your system can perform disk writes at the rate of 60 megabytes per second and you have a 2.4 terabyte database, then it will take at least 12 hours for SQL Server to prep the disk before the actual restore can begin. In reality, the delay may be even longer than what you calculate by as much as 20% to 40%."

However, the Client Read Timeout will only go to 32767 seconds (9+ hours).  A guarantee that a large SQL restore will still fail.  Our SQL database is not there yet, but once fully populated, will be in the TB's range.

Best wishes and until then,