After Upgrade 7.5.0.7 sql and file backups are finished 239

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

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.

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

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

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

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).

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

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.

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 ?.

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)