Video Screencast Help
Symantec Appoints Michael A. Brown CEO. Learn more.

Microsoft SQL Agent Backups

Created: 23 Apr 2014 • Updated: 26 May 2014 | 6 comments
This issue has been solved. See solution.

We recently began to finally use the SQL agent to perform our backups as opposed to doing daily SQL dumps that are then picked up nightly by NBU...

This is not so much an issue as I know the fix, but I am still seeking the reasoning for the behavior and the best way to deal with it.

Our master server runs on AIX and then we have a 5230 appliance and the client in this case is a SQL server running on a Windows 2008 R2 VM.  The VM itself is backed up nightly using a vmware intelligent policy.  As a result of this method, the client name is upper case.  For all of our client side backups (physical/non-vmware) we list the clients in the policy as lower case and because of this, when we made the SQL agent policy, we added the clients as lower case.

Essentially what I see is this:

1. physical server, added to policy as lowercase, backed up normal.  SQL agent policy, client added as lower case, SQL admin script has client as upper case, backup runs and everything completes successfully.  In the activity log, the SQL agent backup appears all lower case as well.  Life is good...

2. VM, intelligent policy backs up the server as upper case.  SQL agent policy has the client as lower case, SQL admin script is upper case.  When the backup runs, it fails saying the server does not exist in the policy and lists the server as upper case.  in the activity log, the parent job lists the client as upper case.  If I change the server in the policy from lower case to upper case, it backs up fine.

So, what I am trying to determine is why the SQL agent policy behaves different for the 2 cases.  why would it look at one server and put it in the activity log as lower case, but then look at the other as upper case.  They are both in the SQL agent policy as lower case.  They are both in the SQL backup script as upper case.

The fix is to simply add the client to the policy as upper case and then it backs up fine, but why would it behave differently for each client.

Operating Systems:

Comments 6 CommentsJump to latest comment

Linette V's picture

This technote might help answer your query: http://www.symantec.com/docs/HOWTO69710 

I think it comes down essentially to Unix case sensitivity and the system beign very literal about exactly what it's been told to back up.

Andrea Bolongaro's picture

We had same issue only after upgrading to v.7.5.0.7.

We opened a case for it and after a while the following technote was out:

MS SQL and other XBSA Backups fail with status code 239 reported after applying the NetBackup 7.5.0.7 maintenance release.
 http://symantec.com/docs/TECH215866

Before 7.5.0.7 we were using hostnames as lowercase for sql agent policies.

Hope it helps.

 

SOLUTION
Mark_Solutions's picture

This is fixed in 7.6 but for now you do need to get the case matched for the policies according to how you decide to run your SQL backups

The difference is that it gets the name from vCenter when using the VMware policy and from the NetBackup Client itself, the policy and the script file when using a SQL policy type

Authorised Symantec Consultant

Don't forget to "Mark as Solution" if someones advice has solved your issue - and please bring back the Thumbs Up!!.

Andrea Bolongaro's picture

We had same issue after upgrading to 7.5.0.7.

Before upgrading, we used ms sql client hostnames as lowercase for both ms sql agent backups and standard backups without any problem.

It is described in following technote

MS SQL and other XBSA Backups fail with status code 239 reported after applying the NetBackup 7.5.0.7 maintenance release

 

CRZ's picture

Andrea Bolongaro has tried twice to share this TechNote in this thread but I think it's hitting our filters.  It's a 7.5.0.7 issue, so I'm not sure if it's affecting you or not:

MS SQL and other XBSA Backups fail with status code 239 reported after applying the NetBackup 7.5.0.7 maintenance release.
 http://symantec.com/docs/TECH215866


bit.ly/76LBN | APPLBN | 75LBN

Mark_Solutions's picture

I have now published Andrea's comment so that you can see it

Authorised Symantec Consultant

Don't forget to "Mark as Solution" if someones advice has solved your issue - and please bring back the Thumbs Up!!.