Showing results for 
Search instead for 
Did you mean: 

Backups failing with status 59

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


Level 6
Partner    VIP    Accredited Certified

From what server you run bptestbpcd?
what netbackup installation you perform on TCMDADOS01.tcm.go (media or client)?

please post a screenshot from the servers list from the client properites



tcm-media-01.tcm.go is another Media Server. I tried adding TCMDADOS01.tcm.go to this registry variable, but bptestbpcd gives me status code 23 - socket read failed.

I tried bptestbpcd to a Linux client, and it worked. Then I tried bptestbcd to another Windows client, but got the same error. Maybe this is somehow related to Windows?

Hi @j_mendes 

Looks like a name resolution issue of some kind (maybe someone has changed/broken WIndows DNS). 

Anyway, can you run the following commands on both the master (tcm-mst-01) and the Windows client (tcddados01) and post the results please?.

# bptestnetconn
# bpclntcmd -self
# bpclntcmd -pn -verbose


I am attaching the requested command's outputs.


Hi @j_mendes 

Not really sure but something from your original bprd log looks suss. 

10:18:03.693 [555629.555629] <2> isHostidMatchesWithHostname: TSS based cache not-used for hostid:213d150f-14a9-4ea4-9f65-4c99074bd08b
10:18:03.693 [555629.555629] <2> getAliasesForHostidCache: Checking cache for hostid:213d150f-14a9-4ea4-9f65-4c99074bd08b for master:tcm-mst-01.tcm.go
10:18:03.695 [555629.555629] <2> _fetch_cs_cache_info: Successfully queried allowedlist cache (hostid_to_alias:tcm-mst-01.tcm.go:213d150f-14a9-4ea4-9f65-4c99074bd08b): {"hostMappings": [{"mappedHostName": "tcmdados01.tcm.go", "isApproved": true, "isConflicting": false, "isAddedManually": false, "origin": "CERTIFICATE_DEPLOYMENT", "isShared": false, "createdOn": 1632236872000, "updatedOn": 1632236872000}, {"mappedHostName": "tcmdados01", "isApproved": true, "isConflicting": false, "isAddedManually": true, "origin": "USER_ADDED", "isShared": false, "createdOn": 1632238102000, "updatedOn": 1632238102000}], "timeToLiveInMin": 60}
10:18:03.695 [555629.555629] <2> validateCacheStatus: Matching entry found in cache

It seems to be implying that the master thinks the client is an alais for the server (I could be misinterpeting the log mind).

Can you check in the GUI under "security Management -> Host management and host mappings that you don't have any incorrect mappings (e.g. the client tcddados01 isn't mapped to the master server tcp-mst-01). 


I don't see anything strange with the host mappings. tcm-dados-01 is mapped to three alias, its FQDN, its shortname and its LAN IP. tcm-mst-01.tcm.go is mapped to its FQDN and its LAN IP.

Another test we tried was with a Windows client that is not in a Windows domain (tcm-dados-01 is in a Windows domain). It worked. Maybe it is somehow related to that. I am discarding the possibility of it being a Windows thing, since it worked with this "not in a domain" client.

Hi @j_mendes 

I'm at a loss - if noone else on here can help, I'd suggest opening a support case and get them to look at this. 

I'm guessing the problem is going to turn out to be something simple. 

If support does resolve the issue, can you please report back here what the solution was?



Did you access the Windows client side and clear host cache for the NBU client s/w side? If not, try that and then do your test again. The key thing here is to check DNS, host name exactness (is that even a word? ), and make sure that the reverse host name lookup isn't failing. IMHO, those are good things to try and test.


Hi @j_mendes 

Can you clarify please - you have referred to one of your problem clients as TCDDADOS01.tcm.go, tcp-dados01.tcm.go and tcd-dadso-01. 

What is the actual client name and are all the above interchangable?
Is the client hostname, the same as the NetBackup client name and/or the DNS name for the client?
What does "bpclntcmd -ip" return?
What about the output of bpclntcmd -hn <name> for all the above names return?


Actually the Netbackup client name and hostname are the same: tcmdados01.tcm.go. There is no other hostname or alias such as TCDDADOS01.tcm.go, tcp-dados01.tcm.go and tcd-dadso-01. Below are the requested command's outputs run from the master server:

[root@tcm-mst-01 ~]# /usr/openv/netbackup/bin/bpclntcmd -hn TCMDADOS01.tcm.go
host TCMDADOS01.tcm.go: TCMDADOS01.tcm.go at
aliases: TCMDADOS01.tcm.go

[root@tcm-mst-01 ~]# /usr/openv/netbackup/bin/bpclntcmd -ip
host tcmdados01.tcm.go at
aliases: tcmdados01.tcm.go


I don't think anyone has asked to see the client config registry/bp.conf of the client. Would it be possible to see that?


There it is. I couldn't find anything out of ordinary... 

Hi @j_mendes 

My only other suggestion is to uninstall the client software (then clean up the directory if required) and reinstall. You may need a reissue token for the install to complete but you will know soon enough.

BTW, what version of NetBackup is in use on the master and the client?



What happens when you ping client with host name TCMDADOS01.tcm.go ? What IP it resolves ? I see it’s resolving to loop back.

You may want to revisit the host entries of client or verify dns resolution from master and client both.

Host TCMDADOS01.tcm.go ( is not an authorized server for host tcmdados01.tcm.go.
10:18:58.577 [555644] <16> bptestbpcd main: Request from host TCMDADOS01.tcm.go ( to host TCMDADOS01.tcm.go ( is not allowed access. Host TCMDADOS01.tcm.go ( is not an authorized server for host tcmdados01.tcm.go.

We already tried reinstalling the client, but it didn't fix the issue. Both client and master server are in version 9.1. I tried upgrading another client that is having the same issue to version, but it didn't work either.

Pinging TCMDADOS01.tcm.go from the master server resolves to If I ping TCMDADOS01.tcm.go from TCMDADOS01 itself, it resolves to  localhost IPv6 (::1). But I don't think that's related to the issue, because another client that is not having the issue is pinging ::1 when I ping its hostname from itself.

Pinging TCMDADOS01.tcm.go [::1] with 32 bytes of data:
Reply from ::1: time<1ms
Reply from ::1: time<1ms
Reply from ::1: time<1ms
Reply from ::1: time<1ms

Ping statistics for ::1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms

I believe that’s the problem…. As when master trying to reach client it’s reaching over ipv4 but client himself resolving to ipv6. And if the IP doesn’t match to name the resolved you get error 59. Do you have host entries locally on client resolving to ipv4? Also try to disable ipv6 if it’s not in use. I have seen it conflicts many times.

   VIP    Certified


Run this ping with -4 switch to use IPv4...

show outcome...