NetVault Plug-in for SQL Server 12.0 - User Guide

Standalone deployment

You can set up one machine as both the NetVault Backup Server and the SQL Server, that is, all software installation and configuration requirements are performed on a single machine. However, Quest recommends that these two entities exist on separate machines.

High-availability deployments

Whether you choose to deploy an Active/Passive or Active/Active configuration, Microsoft requires that you install and configure failover clustering. High-availability deployments include:

Failover Clustering

SQL Server Failover Clustering (Active/Passive) provides high-availability for an entire SQL Server Instance. For example, you can configure a SQL Server Instance on one node of a failover cluster to fail over to a different node in the cluster during a failure or planned upgrade.

A failover cluster is a combination of one or more nodes (hosts) with two or more shared disks, known as a resource group. The combination of a resource group, its network name, and an IP address that makes up the clustered application or server is called a Virtual Server. A Virtual Server appears on the network as if it were a single computer, but provides failover from one node to different node if the current node becomes unavailable.

IMPORTANT: In NetVault Backup terminology, a cluster node is called a Virtual Client. The references to Virtual Client in Plug‑in for SQL Server are basically references to the Virtual Server in a SQL Server Failover Cluster environment or AlwaysOn Availability Group.

Using the failover cluster network name, the Plug‑in for SQL Server identifies the current node that is in control of the SQL Server Virtual Server and targets it for backup.

Make sure that you use the same Windows Server to host the Cluster Core Resources group and to take the active role. The Cluster Core Resources group contains the IP address, network name, and the disk witness. For the Virtual Client to function correctly, the Windows Server that hosts the Cluster Core Resources group, that is, the host identified as the Current Host Server, must be the same node that holds the active role. If failover occurs and the active role moves to a different host but the Cluster Core Resources group does not, the Virtual Client cannot access the active host. The Virtual Client must resolve the IP address for the cluster to the server that takes the active role.

If necessary, such as after a failover occurs, use Windows PowerShell or a command prompt to move the Cluster Core Resources group to the active host.

PowerShell example: Move-ClusterGroup "Cluster Group" –node <ClusterNodeName>

Command prompt example: cluster group "Cluster Group" /Move:<ClusterNodeName>

AlwaysOn Availability Group

You can use the plug-in with the AlwaysOn Availability Groups that you have created on top of your WSFC cluster. In addition to backing up data, you can use the plug-in to manage the addition and removal of the primary and secondary replicas during a restore process. This option eliminates the need to use SQL Server Management Studio to add and remove the replicas.

To ensure that the plug identifies a Virtual Client as running on an AlwaysOn Availability Group, enter valid credentials for the All Instances node located under the applicable Virtual Client in the selection tree. The credentials must let the plug-in log in to at least one SQL Server Instance that is a member of the group. For more information, see Configuring the plug-in.

NOTE: Quest recommends creating backups that include no more than 100 databases in an AlwaysOn Availability Group. There is not an enforced limit for the maximum number of Availability Groups and Availability Databases per machine. The actual number of Databases depends on the hardware capabilities, resources, and workload. However, Microsoft documents that extensive tests have been conducted with 10 Availability Groups and 100 Databases per physical machine. For more information, see: https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/prereqs-restrictions-recommendations-always-on-availability

You can use the plug-in with a SQL Server AlwaysOn Availability Group cluster consisting of two nodes, with each node itself being a WSFC failover cluster, with the two failover clusters at different physical locations, and with only manual failover allowed.

In this case, one of the instances, for example “SQLinstance” is an instance of SQL Server running on the failover cluster with the “primary” role of the AlwaysOn Group. The other instance, for example “SQLDRinstance” is an instance of SQL Server that is running on the failover cluster with the “secondary” role.

If the logins are the same for each instance, then enter valid credentials for the All Instances node located under the applicable Virtual Client in the selection tree.

If the logins are different for each instance, then enter valid credentials for respective instance, that is listed under the All Instances nodes. If the instances are not listed, use the Add Instance action, to enter the credentials for each instance.

When creating the NetVault Backup Virtual Client for AlwaysOn Failover Cluster Instances, provide the IP address of the Virtual Network Name (the “Virtual IP”) of one of the two failover cluster instances that consists the AlwaysOn group. The Virtual IP address of the instance with either the primary role, or the secondary role may be provided. However, if the instance with secondary role is at a remote location from the NetVault Backup Server, Quest recommends using the Virtual IP address of the instance with the primary role for improved performance.

When running backups, you must set the replica selection algorithm as Primary, which is the default algorithm. Backups running using the Secondary replica selection algorithm might perform slow, due to the secondary instance being at a remote location from the NetVault Backup Server.