I'm running netbackup 8.0 on redhat
99% of the servers I back up are Linux Clients. But I have a single Windows box that I need to exclude some files from backups.
I think I should be doing this by going to Host Properties / Clients / Properties / Windows Client / Exclude Lists
But I don't have those options there - it looks like Netbackup believes this is a linux box?
The box is correctly identified as a Windows x64 box when I look at the client list in the Policy
Solved! Go to Solution.
this remained a problem until I updated to NBU 8.2 (linux) - then the server showed up in the Host Properties/Clients as a Windows server
Interesting problem. I suspect but I am unable to test this theory at the moment, that the problem is because you have added the Windows client into a "standard" (aka *nix) backup policy. This is not good practice although it will work - what you find is (if you are using the ALL_LOCAL_DRIVES directive) that you may be missing "stuff" from your backup.
Try creating a new MS-Windows policy with just that client and then refresh the client in host properties. I suspect (and hope) that will change the client type.
If it doesn't you may need to update the host properties in the EMM database - see what "nbemmcmd -listhosts -display_server -machinename uprobob01v -machinetype client -verbose" returns (also repeat using the FQDN). If this shows the type as Linux, then use the "nbemmcmd -updatehost -machinename uprobob01v -machinetype client -operatingsystem windows" to change.
Alternately you could try using the "bpsetconfig" command to push an exclude list to the client, or log into the client run the BAR GUI and update the exclude the list or (and only for the brave) update the registry directly - the registry key is "<HKLM>\SOFTWAR\Veritas\NetBackup\CurrentVersion\Config\Exclude"
I set up a new policy with this server as the only client. I had netbackup detect the client OS - and it correctly came up with Windows-x64. Going to the host properties / clients / - right clicking on the client and choosing Refresh Selected did nothing. I went into properties and saw no way to refresh from inside there.
I also tried the command: sudo ./nbemmcmd -listhosts -display_server -machinename u1probob01v -machinetype client -verbose
...and it told me invalid host name. I tried a few variations of the name and fqdn then ran: sudo ./nbemmcmd -listhosts -verbose - and it just reported information about the media server. Should I be using something other than -machinename?
I'll look into bpsetconfig (and report here if I can get that to work) - but in the meantime can you help me understand what is going on with nbemmcmd? That seems like a handy solution that I'd like to get to work.
Hmm - okay the nbemmcmd won't display info on clients - my mistake.
I note that the name of the client is different in the two locations. Could the client be defined in another policy?
Also after you created the new WIndows policy for that particular client, did you refresh the client host properties panel to check that the client name was displayed as entered in the policy?
If all else fails, try removing all references to the troublesome client from all policies. Then check to verify that the client has disappeared from the client host properties panel. Then finally add the client back into an appropriate policy.
...on the topic of exclusion lists, just thought I'd share some info...
...NetBackup Client effectively has three exclude lists to process...
# 1. the list that Windows provides to third party backup clients, of what to exclude...
reg query "HKLM\SYSTEM\CurrentControlSet\Control\BackupRestore" reg query "HKLM\SYSTEM\CurrentControlSet\Control\BackupRestore\FilesNotToBackup"
# 2. NetBackup Client's own private list of what to exclude...
# ...v8.1.1 for Windows has 33 entries...
# 3. the customer / end-user specified list...
nbgetconfig exclude bpgetconfig -M 127.0.0.1 exclude
[bclegg@u1mannbu01p admincmd]$ sudo ./bptestbpcd -client u1probob01v -debug -verbose
10:17:36.323  <2> bptestbpcd: VERBOSE = 0
10:17:36.323  <2> read_client: dname=., offline=0, online_at=0 offline_at=0 offlineres=0 onlineres_at=0 offlineres_at=0
10:17:36.323  <2> read_client: dname=.., offline=0, online_at=0 offline_at=0 offlineres=0 onlineres_at=0 offlineres_at=0
10:17:36.323  <2> read_client: dname=CO_0, offline=0, online_at=0 offline_at=0 offlineres=0 onlineres_at=0 offlineres_at=0
10:17:36.323  <2> read_client: dname=OA_0, offline=0, online_at=0 offline_at=0 offlineres=0 onlineres_at=0 offlineres_at=0
10:17:36.323  <2> read_client: dname=host_info, offline=0, online_at=0 offline_at=0 offlineres=0 onlineres_at=0 offlineres_at=0
10:17:36.335  <2> vnet_pbxConnect: pbxConnectEx Succeeded
10:17:36.335  <2> logconnections: BPCD CONNECT FROM 10.1.24.15.46592 TO 10.1.9.44.1556 fd = 4
10:17:36.338  <2> vnet_pbxConnect: pbxConnectEx Succeeded
10:17:36.365  <8> do_pbx_service: [vnet_connect.c:2186] via PBX VNETD CONNECT FROM 10.1.24.15.50770 TO 10.1.9.44.1556 fd = 5
10:17:36.365  <8> vnet_vnetd_connect_forward_socket_begin: [vnet_vnetd.c:455] VN_REQUEST_CONNECT_FORWARD_SOCKET 10 0xa
10:17:36.430  <8> vnet_vnetd_connect_forward_socket_begin: [vnet_vnetd.c:480] ipc_string 57133
10:17:36.545  <2> bpcr_get_version_rqst: bpcd version: 08000000
1 1 1
10.1.24.15:46592 -> 10.1.9.44:1556
10.1.24.15:50770 -> 10.1.9.44:1556
10:17:36.546  <2> bpcr_get_peername_rqst: Server peername length = 31
10:17:36.546  <2> bpcr_get_hostname_rqst: Server hostname length = 11
10:17:36.547  <2> bpcr_get_clientname_rqst: Server clientname length = 11
10:17:36.547  <2> bpcr_get_version_rqst: bpcd version: 08000000
10:17:36.547  <2> bpcr_get_platform_rqst: Server platform length = 7
10:17:36.548  <2> bpcr_get_version_rqst: bpcd version: 08000000
10:17:36.588  <2> bpcr_patch_version_rqst: theRest == > <
10:17:36.588  <2> bpcr_get_version_rqst: bpcd version: 08000000
10:17:36.629  <2> bpcr_patch_version_rqst: theRest == > <
10:17:36.630  <2> bpcr_get_version_rqst: bpcd version: 08000000
PEER_NAME = u1mannbu01p.int.digsigtrust.com
HOST_NAME = u1probob01v
CLIENT_NAME = u1probob01v
VERSION = 0x08000000
PLATFORM = win_x64
PATCH_VERSION = 220.127.116.11
SERVER_PATCH_VERSION = 18.104.22.168
MASTER_SERVER = u1mannbu01p
EMM_SERVER = u1mannbu01p
NB_MACHINE_TYPE = CLIENT
10:17:36.646  <2> vnet_pbxConnect: pbxConnectEx Succeeded
10:17:36.664  <8> do_pbx_service: [vnet_connect.c:2186] via PBX VNETD CONNECT FROM 10.1.24.15.40963 TO 10.1.9.44.1556 fd = 6
10:17:36.664  <8> vnet_vnetd_connect_forward_socket_begin: [vnet_vnetd.c:455] VN_REQUEST_CONNECT_FORWARD_SOCKET 10 0xa
10:17:36.725  <8> vnet_vnetd_connect_forward_socket_begin: [vnet_vnetd.c:480] ipc_string 57136
10.1.24.15:40963 -> 10.1.9.44:1556
<2>bptestbpcd: EXIT status = 0
10:17:36.774  <2> bptestbpcd: EXIT status = 0
So, the information returned from the client is correct (as you said in your opening post):
PLATFORM = win_x64
Can you please show us a screenshot of the Client's Properties?
(Similar to the one in NBU Admin Guide)
You also have the option of adding exclude list in the client's BAR GUI.
Remember to 'Run as Administrator', otherwise you get 'Read Only' properties.
File -> NetBackup Client Properties -> Exclusions
(Screenshot from BAR GUI on my laptop with NBU Client software installed)
This is the crux of my problem (I think) - the policy knows it's a windows box - but in Host Properties it thinks it is Unix
Not your problem, but I don't really have access to the windows servers - but I will work with the windows admin to see if I can exclude what I need using the BAR GUI.
Last thought - please check /etc/hosts on the master server to see if there are perhaps duplicate entries for this client:
grep u1probob01v /etc/hosts
If you are only using DNS, please check DNS entries as well.
I still think that there is a duplicate somewhere...
Either duplicate host name or duplicate IP in DNS or some hosts file.
Maybe try to do multiple forward and reverse lookups from master and media server.
I have only ever seen this at a customer where a Linux server had the same name or IP address as a Windows server (this was more than 10 years ago - I cannot remember exact details).
I am not sure but in the first screenshot it looks like you have windows and linux clients in one policy? Maybe with the policy type standard?
I guess you have to add a new Windows policy for this machine.
Perhaps there was an issue with a duplicate IP when the machine was first added? But it now has been fixed on the dns side? I don't know.
What I'd like to do is delete the client completely and re-add.
It isn't immediately apparent how to delete the client from the host properties - I will see what I can learn.
I double checked and that client is no longer in any of the policies.
sudo ./bpclient -client u1probob01v - delete --didn't produce an error, so it looked like it worked. But when I restarted the gui, u1probob01v was still under host properties as a Unix client. So problem remains for now
I think the problem is not with the policies - they show the machine (correctly as windows) - I think the problem is under the host properties the client shows up as a unix box.
If you remove the client from ALL policies, it should also be removed from the host properties section. The other place it might live (but shouldn't influence whether it list in hst properties) is in the client attributes section for the master server properties.
Once removed, then add back into an appropraite policy - does 8.0 have the ability to detect the host OS when adding as a client (I don't recall when that feature was added). It might be worthwhile doing that when adding.
Strange problem you have there.
As per @davidmoline , the Client is added to Host Properties from the Policy Config.
When you open the Client Properties for the specific client, NBU connects to the client. The client itself then reports back it's own config.
In your case, there seems to be a 'crossed line' somewhere, because a Linux server is responding.
You need to involve your network team and even server owner to assist with investigation.
This is interesting.
I spoke to the box owner. u1probob01v is a vm. Originally this client was set up as a linux box - but they couldn't get the application to work on linux, so they replaced it with Windows, using the same IP. This was done months ago, so I suspect any cached data would have long ago expired.
What I'm hearing from Marianne and David is what is displayed when I look at the Clients under Host Properties is dynamically created when I go into that link in the gui. It checks all the clients in all the policies and asks them to tell about themselves. One of the clients in one of the policies says "I am u1probob01v and I am a linux server!" Is there any way to tell which client or at least which policy is providing this info? Are there tools in the /admincmd or /bin I can use to query the policies one at a time to figure out which server has it's wires crossed?
Looking at my system - I'm not seeing what is described above. When I look in the Clients under host properties I am seeing a few boxes that have been decommissioned. They are not in any policies. The one difference I've noted so far is that when I select the decomm'd box I'm unable to get into properties (which I can still do on u1probob01v) and I get a little yellow triangle with an exclamation point on that entry. Not all of the decomm'd boxes are showing - I suspect it is just the one's who's IP's have been re-used.
It really looks to me like there is a local database of some sort of the servers that needs some maintenance. u1probob01v was originally loaded as a linux box and I don't know of a mechanism to update it.
You are not going to solve this from within NBU.
Originally this client was set up as a linux box -
My suspicion is the the Linux vm still exists.
Work with the VM admin to dig a bit deeper to find this VM and completely remove it.