cancel
Showing results for 
Search instead for 
Did you mean: 

Backing up volumes in a Windows Failover Cluster

jpriddy
Level 4
Short question:  Is it supported to define the the virtual hostname of one of your clustered applications on an Windows Cluster as a client?


Story:

Netbackup 7.0 Enterprise Server for Windows, 7.0 Standard Client.

I have a Windows 2008 R2 Failover Cluster with several clustered applications installed. 

FC01-A - Node A of the cluster
FC01-B - Node B of the cluster
FC01 - the Cluster name
APP1 - The hostname of a clustered application.  This application has Drive L: as a resource.
APP2 - The hostname of a clustered application.  This application has Drive M: as a resource.

At any given time either application can run on either node of the cluster.

I want to make my failover cluster a Netbackup client.  I currently have the NBU client installed on both nodes of my cluster.   There is a specific directory that I want to back up.  Let's call it "Config".  It exists on both L: and M: on both app servers.  I have set up a backup policy for this application as follows: 

Policy Type: MS-Windows
Client List: both nodes of the cluster
Selections: *:\

I then set up exclusions on both clients for the policy in question.  I excluded *, then added Config do the exception to the exclude list.

I can successfully back everything up.  However, under this configuration, the node that has the L: or M: drive completes successfully, but an error is returned on the node that doesn't own those drives because there is nothing to backup.

The workaround I am currently using is to define as the client for this policy the clustered hostname of the application.  So my client list is APP1 instead of FC01-A and FC01-B.  Same exclusion list as defined before.  My backups complete successfully with no error because that hostname always has access to the files that I want to back up.

Is this supported or is there a reason why I shouldn't back the folder up in this manner?

1 ACCEPTED SOLUTION

Accepted Solutions

J_H_Is_gone
Level 6

What I do.
install NB on the two physical servers, with the client name being the physical servers.

I setup a policy to backup the physical servers: (I call this one physical_clusters)
C:\
System State/Shadow copy (depending on the OS version)

I then setup a policy(s) to get the other stuff.
Logging into one of physical servers I go to Cluster Administrator.
Under Groups I look at the virtual names and see what resources each of them owns.
I then setup a policy to get the resources.

CLSTR_Vserver1
M:\
N:\

CLSTR_Vserver2
P:\
R:\

Now I know I get the items from the physical that I need
and I get the resources no matter what physical server they are currently on.
(NOTE:  if you log into a Vserver and look at the BAR you will NOT see the Vserver name - that is fine.  It works just fine so long as NB is installed on the physical servers)
 

View solution in original post

10 REPLIES 10

Marianne
Moderator
Moderator
Partner    VIP    Accredited Certified
Perfectly supported and very well thought through! Unfortunately not very well documented...

jpriddy
Level 4
Thank you

jpriddy
Level 4

Actually... upon further review it is NOT working as expected.

I have the clients for FC01-A, FC01-B, and APP1 configured identicaly in client properties.  Exact same exclusion lists.  I even went back and selected all of them and edited the exclusion list at the same time to be sure they were all the same. 

When I back up the client using the "real" Windows hostname (FC01-B), it excludes everything except for the directory that i wanted to include... as expected.   When I backup the client using the virtual hostname (APP1), it backs up the entire system, all drives and folders.

Any ideas?

jpriddy
Level 4

OK I got it sorted by setting the APP1 client properties - Universal Settings - "Use Specified Network Interface" -  to the virtual hostname APP1.  I'm not sure why this mattered if the exclusions were the same.

jpriddy
Level 4

Still wrong... changing the Specified Network Interface also changes it for the FC01-B and the other virtual hostnames... seems that this setting sticks per NBU Client install.

I think I'm stuck with backing up each node hostname.

Mouse
Moderator
Moderator
Partner    VIP    Accredited Certified

It is not explained in the documentation properly, but I did some research regarding the backup of active/active cluster.

What you need to do:
1. Install NBU client to both nodes using nodenames as client name (i.e. FC01-A and FC01-B in your case)
2. DO NOT specify any REQUIRED_INTERFACE (it useless as it's impossible to guess which virtual IP will be owned by a node)

Next we need to introduce Virtual hostnames to NBU. In NBU these entities are called as app_clusters:

In this example we will create two app_clusters:

nbemmcmd -addhost -machinename APP1 -machinetype app_cluster
nbemmcmd -addhost -machinename APP2 -machinetype app_cluster

Now we need to add nodes to these clusters:
Cluster APP1, substitute master_name with your master's hostname

nbemmcmd -updatehost -add_server_to_app_cluster -machinename FC01-A -machinetype client -clustername APP1 -netbackupversion 7.0 -masterserver master_name
nbemmcmd -updatehost -add_server_to_app_cluster -machinename FC01-B -machinetype client -clustername APP1 -netbackupversion 7.0 -masterserver master_name

Cluster APP2, substitute master_name with your master's hostname

nbemmcmd -updatehost -add_server_to_app_cluster -machinename FC01-A -machinetype client -clustername APP2 -netbackupversion 7.0 -masterserver master_name
nbemmcmd -updatehost -add_server_to_app_cluster -machinename FC01-B -machinetype client -clustername APP2 -netbackupversion 7.0 -masterserver master_name

Basically, that's it. Now you can use APP1/APP2 as a client name if you want to backup shared resource and NBU will reroute your request to corresponding node which owns the IP and FC01-A/FC01-B if you want to backup something on the node level (like System_State).

This seems to be only solution that allows to backup active/active clusters, I don't know why it is not documented at all.

 

Will_Restore
Level 6
Why do you need two app_clusters?

Wouldn't you have one app_cluster named FC01 per the original post?

Mouse
Moderator
Moderator
Partner    VIP    Accredited Certified
Maybe I'm missing something in the original post but author has two application with virtual hostnames, FC01 seems to be a node name not a virtual IP of application

J_H_Is_gone
Level 6

What I do.
install NB on the two physical servers, with the client name being the physical servers.

I setup a policy to backup the physical servers: (I call this one physical_clusters)
C:\
System State/Shadow copy (depending on the OS version)

I then setup a policy(s) to get the other stuff.
Logging into one of physical servers I go to Cluster Administrator.
Under Groups I look at the virtual names and see what resources each of them owns.
I then setup a policy to get the resources.

CLSTR_Vserver1
M:\
N:\

CLSTR_Vserver2
P:\
R:\

Now I know I get the items from the physical that I need
and I get the resources no matter what physical server they are currently on.
(NOTE:  if you log into a Vserver and look at the BAR you will NOT see the Vserver name - that is fine.  It works just fine so long as NB is installed on the physical servers)
 

Christoph_Linde
Level 5
Employee
Hi,

the app_cluster feature is not intended for the use you suggest here. It is only for having media servers or san media servers running in an application cluster. So do not use it in this case!

You have to create three policies.

1. One policy is the normal Node OS Backup (as mentioned J Hinchcliffe)
    include System_State and C:\ (perhaps D:\ if it is also node local)
    Clients are the node_names FC01-A and FC01-B
2. One policy is for each cluster service (so you need two policies)
     include the resource drive  of the clustergroup (L:)
    and the virtual name of the cluster (APP1)


All is described in the High Availability Guide (http://seer.entsupport.symantec.com/docs/290237.htm) beginning from page 88-90. Read it, then you will fully understand. It is written in the docs.