10-01-2021 07:21 AM
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
10-01-2021 08:11 AM - edited 10-01-2021 08:36 AM
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
10-01-2021 10:08 AM
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.
10-01-2021 10:10 AM
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?
10-01-2021 05:25 PM
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
Cheers
David
10-04-2021 07:33 AM
I am attaching the requested command's outputs.
10-04-2021 03:59 PM
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).
Cheers
David
10-05-2021 06:09 AM
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.
10-05-2021 03:11 PM
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?
Thanks
David
10-06-2021 10:51 AM
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.
10-06-2021 03:16 PM
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 10.10.110.4" return?
What about the output of bpclntcmd -hn <name> for all the above names return?
Cheers
David
10-07-2021 07:37 AM
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 10.10.110.4
aliases: TCMDADOS01.tcm.go 10.10.110.4
[root@tcm-mst-01 ~]# /usr/openv/netbackup/bin/bpclntcmd -ip 10.10.110.4
host 10.10.110.4: tcmdados01.tcm.go at 10.10.110.4
aliases: tcmdados01.tcm.go 10.10.110.4
10-07-2021 09:21 AM
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?
10-07-2021 01:12 PM
There it is. I couldn't find anything out of ordinary...
10-07-2021 02:32 PM
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?
David
10-07-2021 05:46 PM
10-08-2021 06:01 AM
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 9.1.0.1, but it didn't work either.
10-08-2021 06:16 AM
Pinging TCMDADOS01.tcm.go from the master server resolves to 10.10.110.4. 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
10-08-2021 09:37 PM
10-11-2021 03:22 AM
Hey
Run this ping with -4 switch to use IPv4...
show outcome...