After Upgrade 7.5.0.7 sql and file backups are finished 239

[nurgul]

Hello,

After Upgrade Netbackup  7.5.0.7 sql and file backups are finished 239. For solution, Yes we can edit the client name or bp.conf or registry client name, but for which client. We have 600 clients and we are giving this error after upgrade the 7.5.0.7. And also if we change client name in policy, on the deduplicaiton disk mini catalog we have 2 name version of client and system looking new client name. But new client name folder is empty. System still writing old client name folder, so that reason we have 191 error code.

How can we fix that case sensevity or name problem?

[RamNagalla]

does the backup is triggering from the Netbackup or any other scheduler?

EC 239 is definatly  not because of the upgrade.. 

is the any other change happend??

some time it do happen when the client is part of cluster or having the mulitple network interfaces. where its using the differnt interface to communicate the master.

when you see the error what is the policy name you are seeing..?

you need to enable the bprd log in the master server to identifiy the the server name that is reciving the backup request..

so go ahead and enable the bprd log in the master server and check it to find.

also check

http://www.symantec.com/business/support/index?page=content&id=TECH42954

[Marianne]

I agree with Nagalla. I cannot see that the upgrade would cause the issue.

Are you saying that ALL backups are failing with 239?

How are the backups kicked off?

As per Nagalla's post, please ensure that bprd log folder exists on the master server. 
If not, create the folder and restart NBU to enable logging.

After next failure, please upload bprd log as File attachment.

Not sure where status 191 fits in this picture? Do you have disk staging that has a fixed duplication schedule? If this is this case, the status 191 is understandable - if there are no successful backups, there will be nothing to duplicate.

[nurgul]

Hello,

Thanks for reply.

Not all backup, after upgrade issue happend randomly. Last week 30 clients gives that error, this week 10 clients. But enviroment does not changed.

We have not cluster sql, also we are taking this error for file backup.

And I am not alone, look at that;

https://www-secure.symantec.com/connect/forums/error-239-sql-jobs-after-7507-upgrade

[RamNagalla]

Does the file backups are schedule from Netbackup or any other tool triggering the backups?

[Will_Restore]

ah, some others have had this issue it seems:

Last week I applied MR 7.5.0.7 and imedialty upon the next run of jobs several sql jobs faile with error 239

https://www-secure.symantec.com/connect/forums/error-239-sql-jobs-after-7507-upgrade

[sclind]

I just upgraded to 7.5.0.7 and started having this problem. My clients are defined as 'hostname.domainname.com' yet come into the backup master as just 'hostname' (and then fail).

[sclind]

we added just 'hostname' to the policy and seem to be OK.

[Removed]

Hi,

We had the same issue and it turned out to be a problem with the bch files on the client. We always use only lowercase names for the FQDNs for our backup clients. (We have a dedicated backup network, so each client has a dedicated FQDN for backup) However the windows guys at some point switched to upercase names for the production itnerfaces. Sometimes the MSSQL admins would forget this difference and used the uppercase name for the bch file. (Backup names are always the same as the rpod names with just an add to the name)

So Server was named: PROD-NAME.something.com

Backup name should have been prod-name-bpg.something.com

but was PROD-NAME-bpg.something.com in the bch file

Before 7.5.0.7 this was apparently ignored by NetBackup. With 7.5.0.7 this now cause the 239 error. Now you could of course simply modify the name to uppercase in the policy but I would not be confident that you'll always find your old backup images this way. So we had the MSSQL Admins modify the bch files accordingly.

Nasty little change especially because it is next to impossible for NetBackup admins to find this before upgrading to the new version.

[briggsy]

Hi,

I installed the 7.5.0.7 patch update a couple of weeks ago and all the SQL policies continued running perfectly.

However yesterday I renamed all of them using bppolicynew 'oldname' -renameto 'newname' and now they are ALL failing with 239 !

The .bch files all have the 'sqlhost' and 'browseclient' set to the virtual instance name which is uppercase and not the fqdn name which is in the policy, so would appear to be the same issue as above.

Are Symantec going to produce an EEB for this ?.

[CRZ]

Are Symantec going to produce an EEB for this ?

I've seen a few threads about this now, but has anybody opened a Support case to get an escalation and an Etrack opened?  I couldn't find any but I may not have looked hard enough.

It certainly sounds like something Engineering would consider an EEB for, but they need to know about it first!  (I can try to tell them, but they usually ask me for case and Etrack IDs)

[briggsy]

Hi CRZ,

Yes I've raised a support case for this issue and have some diagnostic info and test data to gather.

I've installed 7.5.0.7 twice now, and had 2 different scenarios with SQL cluster backups. I now have SQL backups working successfully (again) after reverting the Master back to 7.5.0.6, leaving the media servers at 7.5.0.7.

1. First applied 7.5.0.7 late December/early January. The SQL cluster backups started failing immediately with the 239 error. I reverted back to 7.5.0.6 on Master and all 4 media servers.
2. Thought I’d have another go as I had a bit more time and applied 7.5.0.7 again approx. 2 weeks ago. This time all SQL cluster backups continued to work successfully. Last week I renamed all the policies using command line ‘bppolicynew –renameto’  and again the SQL cluster backups started failing immediately with 239. Non-cluster SQL backups continued to work normally. This is when I backed out 7.5.0.7 on the master only.

[nurgul]

we opened the case symantec and enginner recommend that technote but nobody find command :)

For NetBackup 7.5.0.7 and newer, run the following dedupecatutil command to repair all existing client name case sensitivity issues on the media server:
/usr/openv/pdde/pdcr/bin/dedupecatutil –repair_client_name_case

releated article;

www.symantec.com/business/support/index?page=content&id=TECH207194

[Will_Restore]

You are looking on the 7.5.0.7 Media server, right?, and not the Master which was reverted to 7.5.0.6

[spillo1981]

we had the same problem with DB2 and Oracle RMAN script...

For the moment we solved the situation changing in each client the CLIENT_NAME from lowecase to uppercase into bp.conf file... 

But it is very incredible!!!

[spillo1981]

http://www.symantec.com/business/support/index?page=content&id=TECH215866

[CRZ · Accepted solution]

Thanks for that link - here's a bit of an update:

An EEB for 7.5.0.7 is now available for the issue in TECH215866 by contacting technical support, referencing TECH215866 and Etrack 3439790.

This issue does NOT affect NetBackup 7.6.0.x.

We'll update and republish TECH215866 soon (and probably make sure it's added to the 7.5 Late Breaking News soon after!)

[nurgul]

Thanks everybody. We will open a case for EBB.

Best Regards
 

[SplashMasterson]

We had the same error in January and may have had some part in the creation of the EEB. 

Our maintenance windows are very small, so today was the first opportunitity we had to install EEB 3439790.1. 

Post Install Test: The SQL config file was modified to use uppercase characters while the rerun policy is still using lowercase. The job is writing successfully, even without the "browseclient" entry, and has progressed past the point where the status code 238/239 errors were occurring. I am going give it a few days before I consider the EEB successful, but progress appears to have been made with the character sensitivity.

*The browse client entry "browseclient=" was intentionally left out in order to test the functionality of the EEB.

[CRZ]

Glad to hear things are progressing for you. 

I am happy to tell you that this is issue is NOT present in and does not affect 7.6.0.x, so please don't let it affect any upgrade plans you might be making.