Support matrix for SQL Server Backup in Azure VMs

You can use Azure Backup to back up SQL Server databases in Azure VMs hosted on the Microsoft Azure cloud platform. This article summarizes the general support settings and limitations for scenarios and deployments of SQL Server Backup in Azure VMs.

Scenario support

Support	Details
Supported deployments	SQL Marketplace Azure VMs and non-Marketplace (SQL Server manually installed) VMs are supported.
Supported regions	Azure Backup for SQL Server databases is available in all regions, except France South (FRS), UK North (UKN), UK South (UKS), UG IOWA (UGI), and Germany (Black Forest).
Supported operating systems	Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 (all versions), Windows Server 2008 R2 SP1 Linux isn't currently supported.
Supported SQL Server versions	SQL Server 2022 Express, SQL Server 2022, SQL Server 2019, SQL Server 2017 as detailed on the Search product lifecycle page, SQL Server 2016 and SPs as detailed on the Search product lifecycle page, SQL Server 2014, SQL Server 2012, SQL Server 2008 R2, SQL Server 2008 Enterprise, Standard, Web, Developer, Express. Express Local DB versions aren't supported.
Supported .NET versions	.NET Framework 4.5.2 or later installed on the VM
Supported deployments	SQL Marketplace Azure VMs and non-Marketplace (SQL Server that is manually installed) VMs are supported. Support for standalone instances is always on availability groups.
Cross Region Restore	Supported. Learn more.
Cross Subscription Restore	Supported via the Azure portal and Azure CLI. Learn more.

Feature considerations and limitations

Setting	Maximum limit
Number of databases that can be protected in a server (and in a vault)	2000
Database size supported (beyond this, performance issues may come up)	6 TB*
Number of files supported in a database	1000
Number of full backups supported per day	One scheduled backup. Three on-demand backups. We recommend not to trigger more than three backups per day. However, to allow user retries in case of failed attempts, hard limit for on-demand backups is set to nine attempts.
Log shipping	When you enable log shipping on the SQL server database that you are backing up, we recommend you to disable log backups in the backup policy. This is because, the log shipping (which automatically sends transaction logs from the primary to secondary database) will interfere with the log backups enabled through Azure Backup. Therefore, if you enable log shipping, ensure that your policy only has full and/or differential backups enabled.
Retention period for on-demand backups	For Full/ Differential/ Incremental backups, the out-of-box retention is 45 days. For Copy-only full backup, you can define a custom retention period.

*The database size limit depends on the data transfer rate that we support and the backup time limit configuration. It’s not the hard limit. Learn more on backup throughput performance.

• SQL Server backup can be configured in the Azure portal or PowerShell. CLI isn't supported.
• The solution is supported on both kinds of deployments - Azure Resource Manager VMs and classic VMs.
• All backup types (full/differential/log) and recovery models (simple/full/bulk logged) are supported.
• For read-only databases: full and copy-only full backups are the only supported backup types.
• SQL native compression is supported if explicitly enabled by the user in the backup policy. Azure Backup overrides instance-level defaults with the COMPRESSION / NO_COMPRESSION clause, depending on the value of this control as set by the user.
• TDE - enabled database backup is supported. To restore a TDE-encrypted database to another SQL Server, you need to first restore the certificate to the destination server. The backup compression for TDE-enabled databases for SQL Server 2016 and newer versions is available, but at lower transfer size as explained here.
• The backup and restore operations for mirror databases and database snapshots aren't supported.
• SQL Server Failover Cluster Instance (FCI) isn't supported.
• Back up of databases with extensions in their names aren’t supported. This is because the IIS server performs the file extension request filtering. However, note that we've allowlisted .ad, .cs, and .master that can be used in the database names.

Backup throughput performance

Azure Backup supports a consistent data transfer rate of 350 MBps for full and differential backups of large SQL databases (of 500 GB). To utilize the optimum performance, ensure that:

• The underlying VM (containing the SQL Server instance, which hosts the database) is configured with the required network throughput. If the maximum throughput of the VM is less than 200 MBps, Azure Backup can’t transfer data at the optimum speed.
  Also, the disk that contains the database files must have enough throughput provisioned. Learn more about disk throughput and performance in Azure VMs.
• Processes, which are running in the VM, are not consuming the VM bandwidth.
• The backup schedules are spread across a subset of databases. Multiple backups running concurrently on a VM shares the network consumption rate between the backups. Learn more about how to control the number of concurrent backups.

Note

• The higher throughput is automatically throttled when the following conditions are met:
  • All the databases should be above the size of 4 TB.
  • The databases should be hosted on Azure VMs that have maximum uncached disk throughput metric greater than 800 MBpS.
• Download the detailed Resource Planner to calculate the approximate number of protected databases that are recommended per server based on the VM resources, bandwidth and the backup policy.

Next steps

Learn how to back up a SQL Server database that's running on an Azure VM.