Error 64 while backup TL onto NAS

Dear All,
I have a problem that I cannot seem to find much info on. I am backing up
SQL 2000 Transaction logs onto a network share (NAS). This share is
connected to the SQL server by a gigabit switch. When backing up the
transactions logs overnight - I find that the SQL server reports errors
"Operating System error 64 (The specified network name is no longer
available). Error 15457 Severity:0, State:1 on large logs (over 1Gb) - it
seems to backup smaller logs ok.
The SQL server is up to date with the SP3a as are the servers (Windows 2K -
SP4). The Transaction logs are 1Gb or over - some are 4Gb+ (this is a
back-end DB for a large web site).
Can someone point me in the right direction please.
PS. I have applied the MS KB813130 hot fix - this has had no effect.
Thanks
Andrew.Andrew,
This suggests that you are overrunning the ability of the target machine to
keep up with your request. We had problems with this at one time (and are
sneaking back up on it again.) Here are a couple posts from Google that
might help you.
http://tinyurl.com/wtm3
http://tinyurl.com/wtmb Jasper Smith, MVP wrote this response about RAID5
drives.
Russell Fields
"andrew" <andrew_loftus@.hotmail.com> wrote in message
news:%23G2XEPRtDHA.1224@.TK2MSFTNGP09.phx.gbl...
> Dear All,
> I have a problem that I cannot seem to find much info on. I am backing up
> SQL 2000 Transaction logs onto a network share (NAS). This share is
> connected to the SQL server by a gigabit switch. When backing up the
> transactions logs overnight - I find that the SQL server reports errors
> "Operating System error 64 (The specified network name is no longer
> available). Error 15457 Severity:0, State:1 on large logs (over 1Gb) - it
> seems to backup smaller logs ok.
> The SQL server is up to date with the SP3a as are the servers (Windows
2K -
> SP4). The Transaction logs are 1Gb or over - some are 4Gb+ (this is a
> back-end DB for a large web site).
> Can someone point me in the right direction please.
> PS. I have applied the MS KB813130 hot fix - this has had no effect.
> Thanks
> Andrew.
>|||Hi Andrew,
My name is Michael and I would like to thank you for using Microsoft
newsgroup.
Before you troubleshoot the SQL Server, I would like you to check if the
network configration is correct and if the status of the network is normal
on your side when the error occurred. I would like to try excluding the
network reason for this problem so that we can narrow down this issue on
SQL Server.
Based on my research, there is a known issue that if the database size is
big, such as 20 GB, and using a network share name for the backup file, it
can fail with Operating System error 64 (The specified network name is no
longer available.) or 121 (The semaphore timeout period has expired.) when
multiple files are used. The workaround is to use the file path instead of
the network share name for the backup file(s).
Does it solve your problem? If not, I would like you to provide more
information so that I can perform further research.
1. How is the issue going on your side now? Did the problem occur before?
Does the problem occur again? Does it occur randomly?
2. Please provide the Sqldiag.txt (by default located in \Mssql\Log) using
Sqldiag utility (Sqldiag.exe by default located in C:\Program
Files\Microsoft SQL Server\MSSQL\Binn). If you are unable to find the
Sqldiag.exe, please search and run the utility. Then please search the
Sqldiag.txt file and provide it to me at v-yshao@.microsoft.com
Also, such issues tend to be complex and take up extensive research time.
I'd like to set your expectations that it may take a while for us to help
you narrow down the problem and we may eventually redirect you to PSS to
continue working with a dedicated Support Professional. If this is
critical, I'd recommend contacting PSS and opening a Support incident to
troubleshoot this further. If you need any help in this regard, please let
me know.
I am standing by for your response.
Regards,
Michael Shao
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.|||Michael,
Thank you for the reply.
I seem to be able to backup the Tlogs to the local disk and only have the
problem when trying to backup to the N/W share. I was backing up to local
disk and have recently purchased this NAS to backup onto (over £3,000) - the
errors occured when using this NAS.
My Tlog files are no bigger than 6Gb at the moment and it is only the bigger
ones (over 1Gb) that seem to give the error. I assume MS software can handle
this kind of transfer with proper "handshaking" to ensure the share does not
get swamped with data it cannot handle. The NAS is a DELL 725n with "Windows
2000" powered software. The disks are configured in a RAID5 array. This
problem does occur on a regular daily basis.
Thanks
Andrew.
I have emailed you the SQLDIAG.TXT seperatly to your email address.
"Michael Shao [MSFT]" <v-yshao@.online.microsoft.com> wrote in message
news:EX4O1RYtDHA.2072@.cpmsftngxa06.phx.gbl...
> Hi Andrew,
> My name is Michael and I would like to thank you for using Microsoft
> newsgroup.
> Before you troubleshoot the SQL Server, I would like you to check if the
> network configration is correct and if the status of the network is normal
> on your side when the error occurred. I would like to try excluding the
> network reason for this problem so that we can narrow down this issue on
> SQL Server.
> Based on my research, there is a known issue that if the database size is
> big, such as 20 GB, and using a network share name for the backup file, it
> can fail with Operating System error 64 (The specified network name is no
> longer available.) or 121 (The semaphore timeout period has expired.) when
> multiple files are used. The workaround is to use the file path instead
of
> the network share name for the backup file(s).
> Does it solve your problem? If not, I would like you to provide more
> information so that I can perform further research.
> 1. How is the issue going on your side now? Did the problem occur before?
> Does the problem occur again? Does it occur randomly?
> 2. Please provide the Sqldiag.txt (by default located in \Mssql\Log) using
> Sqldiag utility (Sqldiag.exe by default located in C:\Program
> Files\Microsoft SQL Server\MSSQL\Binn). If you are unable to find the
> Sqldiag.exe, please search and run the utility. Then please search the
> Sqldiag.txt file and provide it to me at v-yshao@.microsoft.com
> Also, such issues tend to be complex and take up extensive research time.
> I'd like to set your expectations that it may take a while for us to help
> you narrow down the problem and we may eventually redirect you to PSS to
> continue working with a dedicated Support Professional. If this is
> critical, I'd recommend contacting PSS and opening a Support incident to
> troubleshoot this further. If you need any help in this regard, please let
> me know.
> I am standing by for your response.
> Regards,
> Michael Shao
> Microsoft Online Partner Support
> Get Secure! - www.microsoft.com/security
> This posting is provided "as is" with no warranties and confers no rights.
>|||Hi Andrew,
Thanks for your response. Please perform the following tests on your side
so that I can narrow down this issue.
1. Please perform the problematic backup job manually to see if the problem
also occurs.
2. Have you tried the suggestions in my previous post? Please try to use
the file path instead of the network share name for the backup file(s) on
the destination computer. Can you backup the transaction logs?
3. Please try to change the Write Policy for the RAID controller from
Writethru to Writeback. Does it solve your problem?
If not,please provide the following information so that I can perform
further research.
1. When the backup problem occurred, could you connect to the destination
server using the server name?
2. You wrote "it is only the bigger ones (over 1GB) that seem to give the
error." I am unable to find related information on this in the sqldiag.txt
file. Why do you think so, can you describe it in detail?
3.Do you mean that you are unable to backup transaction logs (over 1GB)
using the server name in any situation?
I am standing by for your response.
Thank you,
Michael Shao
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.|||Michael,
Good morning and thanks for your last reply.
1. Yes, the error happens when a manual backup is done.
2. I backed up upto the local drive E:\ - is this what you mean by file
path - or do you mean mapping a drive letter to the share and backing up to
the drive letter?
3. I have changed the RAID system on the NAS from RAID5 to RAID1, I am
waiting for results but it looks good so far, in that a manual backup has
completed where it did not before the conversion. I will know tommorow for
good.
If this does solve the problem - it surely means that there is no
handshaking/communication between two computers on the network - so one can
easily "swamp" the other with data and get an error message. I would have
thought MS Windows was able to cope with this sinario - any comments?
I will let you know tommorow when my nightly backup has completed, I am
quietly hopeful.
Thanks again
Andrew.
"Michael Shao [MSFT]" <v-yshao@.online.microsoft.com> wrote in message
news:7rULUm8tDHA.984@.cpmsftngxa06.phx.gbl...
> Hi Andrew,
> Thanks for your response. Please perform the following tests on your side
> so that I can narrow down this issue.
> 1. Please perform the problematic backup job manually to see if the
problem
> also occurs.
> 2. Have you tried the suggestions in my previous post? Please try to use
> the file path instead of the network share name for the backup file(s) on
> the destination computer. Can you backup the transaction logs?
> 3. Please try to change the Write Policy for the RAID controller from
> Writethru to Writeback. Does it solve your problem?
> If not,please provide the following information so that I can perform
> further research.
> 1. When the backup problem occurred, could you connect to the destination
> server using the server name?
> 2. You wrote "it is only the bigger ones (over 1GB) that seem to give the
> error." I am unable to find related information on this in the sqldiag.txt
> file. Why do you think so, can you describe it in detail?
> 3.Do you mean that you are unable to backup transaction logs (over 1GB)
> using the server name in any situation?
> I am standing by for your response.
> Thank you,
> Michael Shao
> Microsoft Online Partner Support
> Get Secure! - www.microsoft.com/security
> This posting is provided "as is" with no warranties and confers no rights.
>|||Hi Andrew,
Thanks for your response. I am glad to hear that the manual backup works
after the conversion. Hope the backup job also works fine.
The file path which I mentioned in my previous post indicated the local
path. Generally, it is better to backup the database to the local machine
and run some jobs to copy the backup files to the remote machine. In my
opinion, it is a safer solution.
Also, I am not quite clear your concerns about handshaking/communication on
the network. What does the handshaking/communication indicate? What do you
mean by " swamp"? Can you describe your concerns in detail?
I am standing by for the result on your side.
Regards,
Michael Shao
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.|||Michael,
Thanks for your help - all seems to work now I have changed the NAS to RAID
0 from RAID 5.
My concerns are as you mention - surely one windows computer on the network
cannot "swamp" another - surely there is communication between the
computers - like hold on a minute with that data while I just commit what I
have to disk - ok ready now please send the next chunk.
Andrew.
"Michael Shao [MSFT]" <v-yshao@.online.microsoft.com> wrote in message
news:Aq%23G2XLuDHA.1532@.cpmsftngxa06.phx.gbl...
> Hi Andrew,
> Thanks for your response. I am glad to hear that the manual backup works
> after the conversion. Hope the backup job also works fine.
> The file path which I mentioned in my previous post indicated the local
> path. Generally, it is better to backup the database to the local machine
> and run some jobs to copy the backup files to the remote machine. In my
> opinion, it is a safer solution.
> Also, I am not quite clear your concerns about handshaking/communication
on
> the network. What does the handshaking/communication indicate? What do you
> mean by " swamp"? Can you describe your concerns in detail?
> I am standing by for the result on your side.
> Regards,
> Michael Shao
> Microsoft Online Partner Support
> Get Secure! - www.microsoft.com/security
> This posting is provided "as is" with no warranties and confers no rights.
>|||Hi Andrew,
Thanks for your update. It is great that the backup job also works fine.
Generally, when taking backup copy on the network, some protocol will be
used. There are certain Timout and Retry mechanism defined in the protocol.
If there is still no response from the target after using the Timout and
Retry mechanism, the error will occur.
Thanks for using MSDN newsgroup.
Regards,
Michael Shao
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.