Always On MSSQL Availability Groups

Commvault data protection for Always On Availability Groups provides a disaster-recovery solution for databases on SQL Server 2012 and later. Always On Availability Groups support a failover environment for a set of user databases, known as availability databases, that fail over together. An Availability Group client protects availability databases based on the backup preferences and backup priorities configured for the availability group, and provides a single entry point for initiating backups and restores.

Availability Group Client

After installing the SQL Agent on all the physical nodes of an Always On cluster, create a new Availability Group (AG) client. An AG client is a logical grouping of one or more availability groups. You can create separate AG clients for each availability group or use the same AG client for all the availability groups, even if these availability groups belong to different clusters.

For steps to create an AG client, see Creating an Availability Group Client.

Alternatively, if you already have an AG client created, you can add an availability group to the AG client.

For steps to add an availability group to an existing AG client, see Adding Availability Groups to an Availability Group Client.

Note

  • Use the same impersonation account for all the SQL instances of an AG client. For more information, see User Account and Password Management - SQL Server Agent.

  • Configure the user account at the instance level. The availability groups may belong to different clusters under the same SQL AG client, so the permissions will not work at the agent level.

  • This feature is not supported for Volume Shadow Copy Service (VSS).

Backups on an Availability Group Client

You can either use the default subclient or create a new subclient to run backups on availability group (AG) clients. You can run the backup operation the same way that you run backups on a regular SQL subclient.

When you start the backup, the proxy client runs the master process, and then retrieves the backup information from the availability group. Depending on the type of backup, backup preference, and the backup priority, the backup job runs on either the primary replica or one of the secondary replicas. All activities of the master process are logged and available for review in the SQLBackupmaster.log file on proxy client.

Note

  • Full and differential backups always run on the primary replica.

  • Full copy only and transaction log backups run either on the primary replica, if the primary replica is set as the preferred replica for running backups, or on the secondary replica with the highest backup priority.

  • If copy only full (and offload full backup from the Command Center in SP 21 and more recent version) is selected and the job is converted to FULL, backups run only on the primary replica and availability group backup preference will not be honored.

  • For successful backup of availability databases, verify that the secondary replica can communicate with the primary replica, and that the replicas are either Synchronized or Synchronizing. For more information, see Article ID: SQL0018. If you have a restricted network configuration, add the ports used by the Commvault software on all the AG clients.

If the preferred replica for running a backup job is not available to backup, then the backup runs on the next available replica. The backup operation fails if the CVD services on the selected replica are down.

Databases that are not a part of any availability group must be protected by running backups on physical instances.

For steps to run a backup operation, see Backups for SQL Server Agent.

Availability Database Restores

An availability group instance protects a set of user databases, known as availability databases. By default, a database is restored to the same location where it was backed up, and the existing database files are overwritten. Because restores are not allowed on any replica of availability groups, before running the restore, you must remove the database from the availability group. After running the restore operation, you can manually add the database back to the availability group.

Even if you performed the backup on a different replica, run the browse and restore operations from the availability group instance, because all backups are registered against the availability group instance. Run the restore to an instance installed with the same SQL version or later than the instance where the backup ran.

For steps to run a restore operation, see Restores for SQL Server Agent.

Loading...