CommVault Simpana 11 is our current Backup and Recovery solution and encountered the following issue:
Had to recently restore a database from CommVault backup server. Tried to restore the database and errored as the database is part of an Always On Availability Group. Removed the database from the Always On Availability Group. Tried to restore the database from CommVault again. Failed again due to permissions.
Turns out that there are several special instructions when configuring the CommVault iDataAgent on an Always On SQL Server cluster.
- The CommVault agent needs to be installed onto the physical nodes of the cluster before the configuration of the AlwaysOn Availabilty Groups is created and configured.
- When the AlwaysOn Availability Groups are created, to prevent the databases from being backed up twice, set the value of the global parameter BackupAGDBsViaActualInstance to zero.
– IntelliSnap or Volume Shadow Copy Service is not supported with SQL Server Always On.
– When restoring a database, make sure that the database is no longer part of the AlwaysOn Availability Group.
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.
The Golden Rule – TEST BACKUPS AND RESTORES REGUARLY.