Chat now with support
Chat with Support

NetVault Plug-in for SQL Server 12.2 - User Guide

Introducing NetVault Backup Plug-in for SQL Server Planning your SQL Server deployment Installing and removing the plug-in Configuring the plug-in Backing up data
Defining a backup strategy Understanding snapshot-based backups Reviewing the compression features Performing Online VDI backups Performing VSS backups in SQL Server Example of creating a full VDI backup of an AlwaysOn Availability Group on Windows
Restoring data Using the CLI with the plug-in Troubleshooting

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.

Publisher: Install the plug-in on this node regardless of the replication type implemented.
Distributor: If you use a Local Distributor, the Distributor is running on the same node as the Publisher. However, if you use a Remote Distributor, install the plug-in on the Distributor host.
Subscriber: If you want to back up the changed data in a Subscriber database, install the plug-in on the Subscriber hosts. This configuration lets you synchronize the Publication database with the Subscription database after recovery. If the plug-in is not installed on the Subscriber nodes, re-initialize all subscriptions to the publications in the Publication database after recovery.

High-availability deployments on Windows

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:

This guide does not offer instructions on how to set up NetVault Backup’s Application Cluster Support to administer backups and restores of non-SQL Server-related data and files. This process is not plug-in-specific, and you can find complete details in the Quest NetVault Backup Administrator’s Guide.
Before you continue, Quest recommends that you review all cluster-related information provided in the Quest NetVault Backup Administrator’s Guide. That guides helps you understand how the information included in this guide works with SQL Server Failover Cluster and AlwaysOn Availability Group functionality.

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.

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.

Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating