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 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 | China East, China East 2, China North, China North 2, China North 3 |
| 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. Note that the SQL databases that are part of a AlwaysOn AG and are synced from SQL Managed Instance aren't supported. |
| 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.masterthat can be used in the database names. Learn more about the database naming guidelines for Azure Backup.
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.