Video Screencast Help

Can you backup 2 identical SQL instances to one NBU environment?

Created: 22 Oct 2010 | 9 comments
Tim Hansen's picture

I'm currently having an issue with a customer that has setup a Development and Production environments where the MSSQL cluster servers are identical in everything but IP. Even then, the IPs are the same but accessible through a series of natted IPs that differ, located on the upstream firewalls. Overkill, I know.

I'm currently having an issue attempting to install SQL agents on both the dev SQL cluster and the production SQL cluster. The dev environment has been up and running and backing up for some time now and today when I went to go ahead and setup the prod environment, ran into an issue where the SQL instance names are identical.

Does anyone know of a way to backup two SQL instances (using the SQL agent) to the same NBU environment when they utilize the same name? Assigning a different client name and testing hostname resolution and altnames listings work for the configuration checks, but when the MSSQL job is kicked off and the parent job creates a child job with the db name to be backed up, it is populating the SQL instance name, which is already setup and pointing to the dev server, and backs up the dev db data.

NBU environment: Windows 2003 Std SP2

SQL environment: Windows 2003 R2 x64, SQL Server 2005

Comments 9 CommentsJump to latest comment

Will Restore's picture

If they're identical why do you need to back up both? cheeky

If you asking to back up two machines with same name & IP, I don't think NBU (or any network application) can handle that too well.

Will Restore -- where there is a Will there is a way

Tim Hansen's picture

Because our sales team sold it and the customer wanted it. I know it's not a good answer, but it's the reality of what I've been asked to provide.

I may ask the customer to perform DB dumps of the dev environment in lieu of the agent backups. In the meantime I still need to see if this is possible.

MOHAMED PATEL's picture

I feel your pain - sounds very familiar - Salesmen...

Wildshot - configure policy and use IP rather than hostname - this way it would connect to appropriate server...

like I said - Wildshot

If this post is helpful in any way, please vote or mark as solution.
A thumbs UP will do as well....
Regards
Mo

Marianne's picture

Do you have a separate policy for the prod virtual name?

Do you have the prod cluster virtual name in the backup script on the prod cluster?

SQLHOST "Virtual-Prod"

If this a database mirror configuration, NBU will only backup from the 'principal'.

This behaviour is explained in the NBU for SQL Admin Guide (http://www.symantec.com/business/support/index?pag...).

See p. 171 onwards.

Supporting Storage Foundation and VCS on Unix and Windows as well as NetBackup on Unix and Windows
Handy NBU Links

Zahid.Haseeb's picture

Dear Tim hansen listen. First of all as you said that :-

"""" setup a Development and Production environments where the MSSQL cluster servers""""

You mean you have 2 clusters ? One for Production and one for Development ? and both Clusters have same virtual name which are conflicting?

OR

You are trying to create one cluster with same host name ? if yes thn your host name should be different and the both nodes cluster share a single name which will be the virtual name and your NBU Server will take the backup via virtual name

OR what are you trying to say please clearfy 

Any comment will be appreciated. Mark as Solution if your query is resolved
__________________
Thanks in Advance
Zahid Haseeb

zahidhaseeb.wordpress.com

Tim Hansen's picture

4 physical servers.

2 clusters.

Same hostnames for the servers, cluster names, SQL instance names, everything. Even the IPs are identical, but one set of cluster machines will be accessible via a system of NATted IPs that our Networking team figured out how to accomplish.

Marianne:

The policy has configured for the client backup selection the SQL instance name. In this instance, it's like attempting to backup a 2nd client with the same name as the first, and I know how to work around this if it's a physical client, but with a SQL agent creating child jobs I can't get it to play nice. In this instance the two clusters are not mirrored, one is a dev/staging environment that will serve as the customer's testbed and the other is the production cluster.

Marianne's picture

"Same hostnames, cluster names, SQL instance names, everything."

NetBackup uses hostnames. If you do "bpclntcmd -hn <cluster-name>", which IP address is returned? I don't see it as a NBU problem. This is how TCP/IP works...

Even if you configure the prod cluster with the NAT IP's, the child streams are generated by the client itself. It sends a connection request to the master containing the real IP address, not the NAT IP.

You can find evidence of this connection request in the master's bprd log file.

Supporting Storage Foundation and VCS on Unix and Windows as well as NetBackup on Unix and Windows
Handy NBU Links

Tim Hansen's picture
Files\VERITAS\NetBackup\DbExt\MsSql\nabbu.bch SUCCEEDED with STATUS 0 (0 is normal). Elapsed time = 147(0) seconds
15:15:37.996 [5820.6636] <4> DBConnect: INF - Logging into SQL Server with DSN <NBMSSQL_5820_6636_12>, SQL userid <QTSsyseng> handle <0x01d27ce0>.
15:15:37.996 [5820.6636] <4> CGlobalInformation::CreateDSN: INF - A successful connection to SQL Server <KOFCSQLX\> has been made using standard security with DSN <NBMSSQL_5820_6636_12>
15:15:37.996 [5820.6636] <4> DBDisconnect: INF - Logging out of SQL Server with handle <0x01d27ce0>
15:15:37.996 [5820.6636] <4> DBConnect: INF - Logging into SQL Server with DSN <NBMSSQL_5820_6636_12>, SQL userid <QTSsyseng> handle <0x01d24e20>.
15:15:37.996 [5820.6636] <4> DBDisconnect: INF - Logging out of SQL Server with handle <0x01d24e20>
15:15:37.996 [5820.6636] <4> DBConnect: INF - Logging into SQL Server with DSN <NBMSSQL_5820_6636_12>, SQL userid <QTSsyseng> handle <0x01d27000>.
15:15:37.996 [5820.6636] <4> DBDisconnect: INF - Logging out of SQL Server with handle <0x01d27000>
15:15:37.996 [5820.6636] <4> CDBbackcat::GetVirtualServer: INF - Accessing database instance <KOFCSQLX> on virtual server <KOFCSQLX>.
15:15:37.996 [5820.6636] <8> dbc_GetServerClientConfig: WARNING - NBU's client name= <NT-KOFC-kofcwsql01-p> differs from gethostname()= <KOFCWSQL01> 
15:15:38.059 [5820.6636] <2> vnet_vnetd_service_socket: ../../libvlibs/vnet_vnetd.c.2054: VN_REQUEST_SERVICE_SOCKET: 6 0x00000006
15:15:38.059 [5820.6636] <2> vnet_vnetd_service_socket: ../../libvlibs/vnet_vnetd.c.2068: service: bprd
15:15:38.293 [5820.6636] <2> logconnections: BPRD CONNECT FROM 10.202.7.70.4473 TO 10.202.2.20.13724
15:15:38.605 [5820.6636] <8> dbc_GetServerClientConfig: WARNING - NBU's client name= <NT-KOFC-kofcwsql01-p> differs from gethostname()= <KOFCWSQL01> 
15:15:38.652 [5820.6636] <2> vnet_vnetd_service_socket: ../../libvlibs/vnet_vnetd.c.2054: VN_REQUEST_SERVICE_SOCKET: 6 0x00000006
15:15:38.652 [5820.6636] <2> vnet_vnetd_service_socket: ../../libvlibs/vnet_vnetd.c.2068: service: bprd
15:15:38.902 [5820.6636] <2> logconnections: BPRD CONNECT FROM 10.202.7.70.4474 TO 10.202.2.20.13724
15:15:39.215 [5820.6636] <4> CDBbackrec::CDBbackrec: INF - Use standard backup method with policy <KofC.SQLAgent>.
 
This is a successful backup from the prod environment, after changing the hostfile entries to point to KOFCSQLX (the sql instance name) and the client selection in the policy to KOFCSQLX. This is also the same client selection I use for the staging environment, which causes conflicts since KOFCSQLX can only point to one IP address.
Tim Hansen's picture

/KOFCWSQL01.MSSQL7.KOFCSQLX.db.pane.~.7.001of001.20101025155207..C

There is the file list. Netbackup is auto-populating the SQL server host (same on both clusters) as well as the SQL instance name (same on both clusters).

Can those two fields be modified? If I modify the SQL host in the .bch the backup fails with a error 2.