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.
|
• |
Regardless of the environment in place, two entities or one, install Plug‑in for SQL Server on the host where SQL Server resides. |
|
• |
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
|
• |
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
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
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.
