Post reply

SQL Server log backup fails sometimes

  • August 20, 2013 at 10:05 pm

    #1643281

    Hi,

    Error message "Operating system error 53(the network path was not found" clearly indicates that the network path could not be found in order to access/create, hence you need to check if the drive letter is disconnected at times with SAN.

    Regards,

  • August 21, 2013 at 12:11 am

    #1643312

    The error message states the destination path can not be reached. This indicates problems on the network or on the SAN level.

    There could be too little bandwith or too much latency on the network. If the problem is storage related, it could be the buffer cache of theSAN can't handle the load or there is too much I/O on the LUN's.

    ** Don't mistake the ‘stupidity of the crowd’ for the ‘wisdom of the group’! **

  • August 21, 2013 at 1:14 am

    #1643335

    Thanks guys. How to troubleshoot this problem? Is there any kind of step by step diagnosis process that we can setup to find the issue?

  • August 21, 2013 at 1:23 am

    #1643339

    And also if the issue is SAN setting related, we should notice the same with other SQL Servers in the mix. However that is not the case. We are seeing this issue just on this machine. Is the problem specific to this machine where we are seeing this issue?

    One of the options that I am thinking off is to take the backups to a local drive and have a file copy to move files from SQL Server host to the SAN drive. Shouldn't the file copy have the same problem?

    Sorry to be vague.

  • August 21, 2013 at 1:36 am

    #1643343

    N Nara (8/21/2013)

    One of the options that I am thinking off is to take the backups to a local drive and have a file copy to move files from SQL Server host to the SAN drive. Shouldn't the file copy have the same problem?

    Create the backup on a local drive is a good idea, it will most likely even speed-up the SQL backup process. If the copy-task will have the same problem is unknown. It depends on the time it takes and on other simultanious actions taking place on the network and SAN. The filesystem is designed to handle files, so I expect the file-copy to be more efficient and maybe even faster.

    ** Don't mistake the ‘stupidity of the crowd’ for the ‘wisdom of the group’! **

  • August 21, 2013 at 1:45 am

    #1643346

    Thanks Hanshi. I probably will go with the local backup option.

    However, I would like to troubleshoot the problem. Any pointers would really help.

  • August 21, 2013 at 2:08 am

    #1643348

    Go for local backup and ask the backup team to backup from that location.

    hope local drives are SAN drives mounted?

    Regards
    Durai Nagarajan

  • August 21, 2013 at 2:15 am

    #1643351

    N Nara (8/21/2013)

    Thanks Hanshi. I probably will go with the local backup option.

    However, I would like to troubleshoot the problem. Any pointers would really help.

    First I would try to determine if the destination will always be reachable. Setup a process (batchfile) to continuously ping the destination server and capture the results. You can ask the network admin to monitor the available bandwith and network troughput from the server to the SAN. Also let the SAN admin monitor the buffer utilisation and I/O activities. Combine all monitoring results to see if anything is out of the ordinary at the time the probllem occurs.

    ** Don't mistake the ‘stupidity of the crowd’ for the ‘wisdom of the group’! **

  • August 21, 2013 at 2:27 am

    #1643352

    If the issue is specific to these backups then check the mountpoint, and LUN setup you are writing to, could be you have a disk within the LUN (or if the LUN is only the 1 disk) that is about to crash and is causing the LUN to destabilise and drop on and off the network.

  • August 21, 2013 at 2:00 pm

    #1643630

    We ran hrping with millisecond timeframes and it didn't show any packet loss.. not sure now.

Viewing 10 posts - 1 through 11 (of 11 total)

You must be logged in to reply to this topic. Login to reply