If you are a database administrator, then you are no stranger to the idea that data must be highly available. High availability simply helps ensure that business operations continue to run with as little downtime as possible. Over the years, Microsoft offered a number of different strategies including (but not limited to) replication, mirroring, log shipping, clustering, and the latest addition being AlwaysOn.
SQL Safe Backup officially supported High Availability Groups with the release of the 7.4 version. Since support for AG became available, it's been a bit of a mystery to some users of what actually changed in the product. I want to take a moment to give a high overview of this in hopes that it might enlighten some users and help in planning a backup strategy.
Ad-hoc versus Policy-based Operations
With SQL Safe Backup, I generally categorize the way a backup operation is initiated into two different types, ad-hoc operations and policy-based operations. Ad-hoc operations are basically operations that you manually kick off manually when needed. Policy-based operations are those that run per a schedule that is defined when a SQL Safe Backup Policy has been created. Under the covers, the main difference between these two types is the fact that the commands used in policy-based operations contain the Policy parameter as shown using the two example commands that I've included below.
- Ad-hoc
"C:Program FilesIderaSQLsafeSQLsafeCmd.exe" Backup Northwind "D:Backup%instance%_%database%_%backuptype%_%timestamp% (%ordinal% of %total%).safe" -BackupDescription "Needed to perform an ad-hoc backup operation." -BackupName "Northwind Backup Example" -CompressionLevel ispeed -Server sasuke -BckDstType 0 -InstanceName sql2016 -BackupFileType 0 -NoPrompt - Policy-based
"C:Program FilesIderaSQLsafeSQLsafeCmd.exe" Backup Northwind "D:Backup%instance%_%database%_%backuptype%_%timestamp% (%ordinal% of %total%).safe" -BackupDescription "This backup policy will perform backup operations against the Northwind database." -BackupName "Full backup for policy Northwind Backup Policy Example" -CompressionLevel ispeed -Server sasuke -BckDstType 0 -InstanceName sql2016 -Policy "4ff25813-1b09-4c44-8d07-e3a56637636f" -BackupFileType 0 -NoPrompt
As you can see from the examples above, the one big difference between the two commands is the inclusion of the Policy parameter (there are some other differences but this is the key difference) and is important as it changes the behavior that SQL Safe Backup has when issuing a backup operations against a database that is participating in an availability group.
Ad-hoc Operations and AlwaysOn
When an ad-hoc operation is executed against a database that is participating in an availability group, SQL Safe Backup submits the backup command as if it were a normal database. Depending on whether the operation was executed against the primary replica or a secondary replica and the type of operation submitted (full, differential, t-log, etc), the operation will either fail or succeed. If the operation fails, you'll likely see a message similar to the following:
This BACKUP or RESTORE command is not supported on a database mirror or secondary replica.
BACKUP DATABASE is terminating abnormally.
The fact that the error is reported in the SQL Safe Management Console is one difference between ad-hoc and policy-based operations. I'll elaborate further in the next section as I describe the behavior with policy-based operations.
Policy-based Operations and AlwaysOn
When configuring a SQL Safe Backup Policy for an AlwaysOn database, it's best to include all the nodes of the availability group. By doing so, you can make sure that the backup schedule is applied to all of the replicas in the availability group.
As I mentioned earlier, policy-based operations include the Policy parameter in the backup command. When this parameter is included, SQL Safe will take an extra step of checking whether the database is part of an availability group and whether it's on the preferred replica by using sys.fn_hadr_backup_is_preferred_replica. If sys.fn_hadr_backup_is_preferred_replica indicates that the node is not the currently preferred replica, then the backup operation will not execute on that particular node. SQL Safe will also not report back any status back to the SQL Safe Management Service given that no operation ran. At the same time, however, an operation should have run on the node that was the preferred replica at the time. The status of that operation will be sent to the SQL Safe Management Service, which can be viewed from the SQL Safe Management Console.
To summarize, Policy-based operations will only execute on the preferred replica which is determined by using sys.fn_hadr_backup_is_preferred_replica. Any operation status that does not originate from the preferred replica will not be seen by users, which helps avoid false alerts from being generated.
Scripting Options
SQL Safe Backup provides users with the ability to initiate backup operations using scripts, specifically through the use of the SQL Safe command line interface (CLI) and the SQL Safe extended stored procedures (XSPs). If you're using either of these for custom backup operations and you want to make sure that they check for the preferred replica, then you may want to consider adding some logic to your scripts so that they check sys.fn_hadr_backup_is_preferred_replica first. With the CLI option, I'm not certain of a good way to do this. Perhaps there is a Powershell command is available that can be used before executing the SQL Safe CLI. For XSPs, the solution is a bit more straight-forward. You would simply need to check sys.fn_hadr_backup_is_preferred_replica before running the script. There's an example that's given on Microsoft's page which discusses sys.fn_hadr_backup_is_preferred_replica.
Closing
If you made it this far, I'd like to hear back from you. AlwaysOn has been around for a few years now and users have some experience with it. What kind of problems have you encountered with backing up databases in an availability group? What are the backup strategies that you find are the best for your environment? Any shared insight can be used to help improve the product for all of our users!