cancel
Showing results for 
Search instead for 
Did you mean: 

Backing up cluster servers (active-active)

Thomas_Anthony
Level 5

Hello Forum Folks, 

NBU Master 7.6.0.3 on Linux Redhat

Trying to correct the backup method currently configured for this cluster.   Right now SERVER_A and SERVER_B are the 2 physical servers of the cluster and are being backed up as separate servers.  Restores have been problematic using this current method.

These are running Microsoft Clustering and create a virtual cluster name of SERVER_AB.  Microsoft SQL was installed in an active-active cluster mode with SERVER_CL1 running on SERVER_A and SERVER_CL2 running on SERVER_B

 

What's the preferred method to backup this cluster ?  Shouldn't the backup policy point to the virtual server SERVER_AB ?

Should it us the flist back list of SERVER_A and SERVER_B, or ALL_LOCAL_DRIVES (excluding anything unneeded) ?

Thanks....

 

 

1 ACCEPTED SOLUTION

Accepted Solutions

sdo
Moderator
Moderator
Partner    VIP    Certified

My oversimplistic (at this stage) advice is... follow the disk resouces...

...I mean... use the network resources which are logically grouped with the disk resources...

...for example...

any disk resources private to nodeA - backup via network resource for nodeA

any disk resources private to nodeB - backup via network resource for nodeB

any disk resources private to nodeC - backup via network resource for nodeC

any disk resources for cluster resource groupD - backup via network resource for groupD

any disk resources for cluster resource groupE - backup via network resource for groupE

.

...therefore... the implication is that... for any cluster resource group which contains a disk resource which contains something that you need to backup... then that cluster resource group also needs to contain a cluster network resource IP address... i.e. a cluster resource group IP and most likely a DNS name too, but the DNS name is not critical (you could use hosts file entries to point to eveything) only the IP for cluster resource group is critical to backups... because you need to be able to follow the resource group (containing the disk resources) as they fail (aka move) around the cluster member nodes.

.

For restores - for this example cluster above - create five altnames files, with all five files containing all five client names from all five of the above, that way you can create one file, and copy it to the four other file names... and now... all three nodes can browse and restore from backups of all five backup policy client names (i.e. the the three nodes + the two resource groups).

View solution in original post

3 REPLIES 3

sdo
Moderator
Moderator
Partner    VIP    Certified

My oversimplistic (at this stage) advice is... follow the disk resouces...

...I mean... use the network resources which are logically grouped with the disk resources...

...for example...

any disk resources private to nodeA - backup via network resource for nodeA

any disk resources private to nodeB - backup via network resource for nodeB

any disk resources private to nodeC - backup via network resource for nodeC

any disk resources for cluster resource groupD - backup via network resource for groupD

any disk resources for cluster resource groupE - backup via network resource for groupE

.

...therefore... the implication is that... for any cluster resource group which contains a disk resource which contains something that you need to backup... then that cluster resource group also needs to contain a cluster network resource IP address... i.e. a cluster resource group IP and most likely a DNS name too, but the DNS name is not critical (you could use hosts file entries to point to eveything) only the IP for cluster resource group is critical to backups... because you need to be able to follow the resource group (containing the disk resources) as they fail (aka move) around the cluster member nodes.

.

For restores - for this example cluster above - create five altnames files, with all five files containing all five client names from all five of the above, that way you can create one file, and copy it to the four other file names... and now... all three nodes can browse and restore from backups of all five backup policy client names (i.e. the the three nodes + the two resource groups).

sdo
Moderator
Moderator
Partner    VIP    Certified

BTW - it is highly unusual, and I'm almost inclined to say incorrect, to ever use ALL_LOCAL_DRIVES in any backup policy for any client or any cluster VIP name for any of which are members of a cluster resource set.

sdo
Moderator
Moderator
Partner    VIP    Certified

All of the above is regarding file level backups only.

You and I both need a NetBackup for SQL master/guru to explain what to also do for SQL cluster member nodes.

What I can add is that very likely any and all excludes and any and all exclude overides (i.e. definite includes) always need to be applied to all member nodes.

Top tip:  don't foget to ensure that    mssqlsystemresource.[lm]df     files are always *included* in the appropriate backups... and if you don't know why... then just take this as written... and if you want to know why... then the MS documentation for SQL has the answer... sorry, but it'll just take too long to explain... or for more detail then search this forum for:   mssqlsystemresource