cancel
Showing results for 
Search instead for 
Did you mean: 

Backups failing with status 59

j_mendes
Level 3

Hello, I am getting this 59 error when performing MS-Windows backups. It started recently. I've seen other VOX posts with this issue discussed, but none of the suggested troubleshooting actions worked, such as checking DNS resolution, reinstalling the Netbackup Client, clearing host cache, renewing certificates, adding the server hostname to the SERVER variable.

I uploaded logs from bprd, bpcd, and bptestbpcd. In our scenario, tcm-mst-01.tcm.go is the Master Server and tcm-dados01.tcm.go is the client. In the logs, you will see that bpcd thinks that tcm-dados01.tcm.go is the SERVER itself which is a behavior I've never seen before. The command I ran was bptestbpcd -client tcmdados01.tcm.go -verbose -debug

25 REPLIES 25

Yes, I have a host entry resolving localhost to 127.0.0.1. I also tried disabling IPv6 in other clients that are experiencing the same issue (disabling IPv6 requires a reboot and I cant reboot tcmdados01) but it didn't solve the issue.

Comparing tcmdados01 with srv-vmb-01, which is another Windows client that is not having this issue, srv-vmb-01 resolves its hostname to an IPv6 link-local address when it pings itself. So that's why I don't think the ping results are related to the issue:

C:\Windows\system32>ping srv-vmb-01

Pinging SRV-VMB-01 [fe80::3911:eeff:9c43:e654%12] with 32 bytes of data:
Reply from fe80::3911:eeff:9c43:e654%12: time<1ms
Reply from fe80::3911:eeff:9c43:e654%12: time<1ms
Reply from fe80::3911:eeff:9c43:e654%12: time<1ms
Reply from fe80::3911:eeff:9c43:e654%12: time<1ms

Ping statistics for fe80::3911:eeff:9c43:e654%12:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms

jhromeror
Level 3

From the client run (if the IP matches to what the client has):

echo REQUIRED_INTERFACE = 10.10.110.4 | nbsetconfig

And restart the NetBackup Services at the client.

This should force NBU to use the 10.10.110.4 for incoming and outgoing comms. There is no reason why it should be wondering around to 127.0.0.1.

 

jhromeror
Level 3

Also, 127.0.0.1 should always resolve to localhost, your CONNECT_OPTIONS rely on that.

I tried that with no success. Still getting the same error. I will attach the following logs: bptestbpcd output,bpcd, bprd. Localhost resolves to 127.0.0.1.

Hi @j_mendes 

Seriuosly, why haven't you logged a support call? They could resolve this in a short amount of time with a shared screen session. I suggested this two weeks ago and yet you are still persisting.

David

I have. It has passed two weeks or more since I opened a case but so far the TSE found no solutions. They are going to escalate this support case to see if it gets resolved more quickly.