Client Ignores exclude list

[felonious_caper]

So I've got 250 or so clients that we back up. All are windows based with various operating systems.

The backup type is "Standard"

Now on most of these clients, they follow the exclude/include list. However, there are a few that do not.

I've tried manually deleting the registry files on the client and then adding them again from the master server, I see the changes take affect, I reboot the machine just to make sure... but they still completely ignore the exclude list. I don't know what to do, or why it does this. All of the clients are running the latest client software. Is there anything else I can check?

Deleting the registry files work on ONE of the clients, but had no affect on the others.

[felonious_caper]

Yes, I deliberatly loaded test jpeg, mp3, and txt files onto the affected machines and checked for their existanace in the catalog.

jpeg and mp3 are supposed to be ignored, txt should not... yet everything is backedup.

I feel like part of the problem is that a lot of people have recently moved from one department to another, we change their alias since it matches their dept name and extension number. I feel like somewhere, netbackup either on the server or the client is holding onto this "old" information. I've tried to uninstall completely and then reinstall the client again but it doesn't seem to help

[felonious_caper]

Ok so here are the two registry files. I noticed the working PC has 2 more fields than the one that isn't

[Mark_Solutions]

Perhaps it is the alias change / IP change that is causing the issue and things are getting cached causing you issues.

If all of these PCs are DHCP and you have a short lease then maybe this is cuasing things to go wrong - although I dont see why ot should affect the exclude lists, but it could cause the wrong PC to be backed up.

You may need to set a scheduled task on the Master and Media Servers to run:

bpclntcmd -clear_host_cache

As by default NetBackup expects all clients (in general servers) to have fixed IP addresses and so caches it and uses that for the next backup to save the time on client resolution.

Just as a test you could run this on the Master and Media Servers and try the backups again - but please set level 5 debug on the "bad" client so that we can see what the bpbkar log says.

[felonious_caper]

bash-3.00# bpclntcmd -clear_host_cache
bpclntcmd: unrecognized option -clear_host_cache
bpclntcmd: -sv
bpclntcmd: -pn
bpclntcmd: -self
bpclntcmd: -hn <hostname>
bpclntcmd: -server <NBU master>
bpclntcmd: -ip <ipaddress>
bpclntcmd: -gethostname
bpclntcmd: -is_local_host <hostname>
bpclntcmd: -check_vxss
bpclntcmd: -check_vxss_with_host <hostname>
bpclntcmd: -get_pbx_port [<hostname>]
bpclntcmd: -get_remote_host_version <hostname>
bpclntcmd: -get_local_client_patch_version
bpclntcmd: -get_local_server_patch_version
bpclntcmd: -sanclient <0|1>
bpclntcmd: -reverse_name_lookup [allowed|restricted|prohibited]

Clear_host_Cache is only an option in 7.0.1

Not going to lie, I was rather excited as this is the kind of response I was hoping for. Back to the drawing board. Is there anything else that cache's information like this? Maybe on the client side?

Also, Should i set the "global logging" to level 5 on the master server via "host properties -> client"

[Mark_Solutions]

Ok - sorry about that - in that case you may be OK as earlier versions did not cache it for very long - maybe only a couple of hours.

If you have set it at the client itself to level 5 then if you view it from the Master via its Host Properties and it does not already say it is set to 5 then you are not looking at the same client!

[felonious_caper]

What I'm asking is HOW and WHERE i set it to level 5. I'd like to do it on the client so I can verify once again the master server is talking to the right machine.

[Mark_Solutions]

OK - Sorry

Open the BAR GUI on the client and select File - NetBackup Client Properties

On the Troubleshooting tab select general level 2 and verbose level 5

When you then connect via the Client Host Properties - Logging tab you should see global set to 5

[felonious_caper]

Ok I'll be on that later tonight after everyone leaves. Also, even though the cache is supposed to be cleared hourly, is there a way to clear it anyways? Maybe something is hanging and not letting go of the cached files? I've also made a habbit of restarting NBU on a weekly basis

Also, on the good client, the client properties are "Read only" and do not allow editing

[Mark_Solutions]

I am guessing that you are accessing it from a Remote Admin Console?

If so can you access the Servers tab of the good client?

If you can add your PC name to its servers list, save and close and then re-open them.

[felonious_caper]

Just needed to "run as admin", I'm all set up on the good client, the other client I'll have to do after 4.

Thank you so much for all of the help and patience, I won't be receiving my formal training in NBU until the 5th of march

[felonious_caper]

Here are the two level 5 logs

Some things I've noticed:

Good Client:
5:52:25.549 PM: [6108.5720] <4> ncfLogConfiguration: INF - Process architecture: 9, Page size: 4096, Process type: 4, Process level: 8664, Processor revision: 6

Bad Client:
5:43:50.812 PM: [2480.2280] <4> ncfLogConfiguration: INF - Process architecture: 0, Page size: 4096, Process type: 2, Process level: 586, Processor revision: 6



Good Client:
5:52:25.701 PM: [6108.5720] <4> ImpersonatePlatform::logImpersonation: INF - Environment variable asl.log=Destination=file

Bad Client:




Good Client:

Bad Client:
INFORMATIONAL: REG_MULTI_SZ registry value "(null)\SYSTEM\CurrentControlSet\Control\BackupRestore\FilesNotToSnapshot" lacks proper termination


Good Client:
5:52:33.757 PM: [6108.5720] <4> tar_backup_tfi::UpdateExcludeListWithVHD: INF - UpdateExludeListWithVHD begin
5:52:34.151 PM: [6108.5720] <2> tar_base::V_vTarMsgW: INF - Estimate:-1 -1
5:52:34.151 PM: [6108.5720] <4> dos_backup::tfs_network_drive_check: DAT - GetDriveType(C:\) returned 3
5:52:34.151 PM: [6108.5720] <4> tar_base::V_vTarMsgW: INF - tar message received from dos_backup::tfs_scannext

Bad Client:
5:43:55.326 PM: [2480.2280] <4> tar_backup_tfi::backup_finishfile_state: INF - catalog messtar_backup_tfi::UpdateExcludeListWithVHD: INF - UpdateExludeListWithVHD begin
5:43:55.226 PM: [2480.2280] <2> tar_base::V_vTarMsgW: INF - Estimate:-1 -1
5:43:55.226 PM: [2480.2280] <4> dos_backup::tfs_network_drive_check: DAT - GetDriveType(C:\) returned 3
5:43:55.250 PM: [2480.2280] <2> tar_backup_tfi::backup_startfile_state: TAR - Backup: C:
5:43:55.250 PM: [2480.2280] <2> tar_backup_tfi::backup_startfile_state: TAR - writing file 0 'C:'
5:43:55.284 PM: [2480.2280] <4> dos_backup::tfs_readopen: INF - NT Security information obtained for: 'C:'

[felonious_caper]

Ok so, I noticed the NAME of the client computer shares the same name as some others (for reasons that weren't fully explained to me). Anyways, I changed the computers name to match it's alias in the master servers host file.... AND IT WORKED! Only problem is, They want the name changed back before the end of the night. How could the computers name cause this type of issue?

[Mark_Solutions]

Both of the logs you posted today said 6.5 GA again - and yet a previous one said 7 and before that it said 6.5

As we have suggested during this thread it very much looks like these backups are not actually backing up the intended clients - and even when you connect to them to get the logs that may also be the wrong client (although it is the one being backed up!)

As the show says - "Confused - you will be!" (or am i showing my age? - anyone remeber Soap?)

And now we have hosts file entries on the Master Server to contend with as well - do all of your PCs have fixed IP addresses? If not then it really looks like there is no certainty as to what you have backed up when.

If you look through the logs it does show by name who's PC is backed up each ti,e so perhaps that is a clue

If you use hosts files on the Master / Media Servers then the time it takes to clear the cache or running the bpclntcmd -clear_host_cache would make no difference .... on that point I have just realised that you tried that command and it didnt work - maybe as some are on 6.5?

Anyway - at this point it does look like things are resolved and just needs all host file entires, IP addresses, PC names and their associated NetBAckup client names checking and you should be fine!

Good luck and hope we have steared you in the right direction

[felonious_caper]

All of the log files say 6.5. I HAVE SAID that it's 7.0. For some reason, bpbkar32.exe hasn't been updated with the release of 7.0.

Either way, I know for a fact that this is the PC that is being backed up. I've tested it by placing marker files on the affected PC and seeing if it exists when trying to restore it from that client and it does.

However, I do not know why netbackup ignores the exclude list if the PC name is not the same as the Master Server host Alias.  It is a little dumb that the PC name would cause problems for an exclude list. I wish this did solve my problem, since 3 or 4 PC's all have the same name and have to have the same name. I cannot have the same alias pointing to 4 different IP's.

[Mark_Solutions]

So on those PCs is the NetBackup Client name the same as the actual PC name?

It may be that causing the issue rather than how the Master Server sees it

[Will_Restore · Accepted solution]

"Ok so, I noticed the NAME of the client computer shares the same name as some others (for reasons that weren't fully explained to me)."

You have multiple machines with the same name?  Can't see how that is supposed to work in networked environment; standalone maybe. 

My earlier query:

are you certain

... of hostname resolution, that we're dealing with the same machines that NetBackup is talking to? 

[felonious_caper]

Mark:

Yes, both the PC name and client name were set to ql2svr. I then changed it to mis3409 to match the host list, but neither work. It's almost as if, the host name and the PC name need to be the same.

wr:

"Yes, I deliberatly loaded test jpeg, mp3, and txt files onto the affected machines and checked for their existanace in the catalog."

"Either way, I know for a fact that this is the PC that is being backed up. I've tested it by placing marker files on the affected PC and seeing if it exists when trying to restore it from that client and it does."