SQL backup failed status 25 & 59

[liuyang]

Hi, my master and media servers are all NBU 7.1 on Windows 2008 R2 SP1. We have a few MS SQL servers (MS SQL 2005, MS cluster, Windows 2008). Previously the MS SQL servers are backed up by media server A and the backup jobs run successfully. Now we want to change them to be backed up by media server B. In media server B, I have already updated the host file. In the MS SQL servers, I also updated the host files and also added server B to the server entry in registry. The network connection seems OK as I can ping the SQL servers from media server B and vice versa.

However, when I run the backup jobs of these SQL servers, they failed with either status 25 or 59.

I would like to know: what else should I change? Any recommended steps for changing media servers? Thanks.

[Marianne]

Double-check reverse lookup on client side. You need bpcd log on client to see incoming server connection request, how server IP address is resolved to hostname and how this hostname is compared to SERVER entries.

If for example IP address is resolved to mediab.xxxxx.yyy but you have mediab in SERVER list, connection will fail.

[watsons]

on those hosts where you had the hosts file changed. Sometimes it's still using the cache info. Restart NBU services on those clients if necessary.

[Marianne]

You can also check comms between media server and client without running a backup:

Ensure bpcd log folder exists on client.

Run the following from cmd on media server (remember to open cmd with Run As Administrator):

.....\netbackup\bin\admincmd\bptestbpcd -client <client-name> -debug -verbose

Please post output of command as well as client's bpcd log file.

[liuyang · Accepted solution]

Thanks a lot for your replies. I opened a case with Symantec support and the issues have been resolved by update the host files in master/media servers and the clients.

[Marianne]

Exactly as I thought - hostname lookup problem. If you posted bpcd log here a week ago when I suggested it, you would have this resolved on the same day.

I am always amazed how you ask for assistance here, ignore requests for more info or logs, then log a call with Symantec (who would request the same info/logs) then come back and mark your own post as solution.

[liuyang]

I try not to post logs here because the logs may contain sensitive info (e.g., hostname and IP address).   

I thought "MARK AS SOLUTION" is to tell everyone the solutions to the issues. In my post, I have indicated that Symantec support solved my issues. So the Solution to my issues in this and some other posts are to contact Symantec support.

[Marianne]

I have personally asked for advice here and posted logs. Because my logs are normally from customer sites, I change hostnames and IP's to generic ones that are still distinguishable like:

master (master.xxxx.yyy) 10.10.10.1
media1 (media1.xxxx.yyy) 10.10.10.2
media2 (media2.xxxx.yyy) 10.10.10.3
client1 (client1.xxxx.yyy) 10.10.10.4

This way we can still troubleshoot without sharing company information.

We would REALLY like to help, but we need you to allow us to help.
If we had a modified bpcd log on 4 April, we would've told you: update DNS and/or hosts files. Same as what Symantec did after you sent them the bpcd log, right?
I even told you what to look for in bpcd log... We all know that DNS or hosts entries are needed for forward and reverse lookup.

Without giving us any information, you might as well log a call with Symantec in the first place and then post your experience here for the sake of sharing information. You can then mark your post with 'I don't need a solution, just sharing information'.

Thanks for coming back to close this post.

I hope that you will allow us to assist in future!