Recommendations for Improving the Performance of Azure SQL Backups and Restores

Protection Scope and Limits

Azure SQL Protection in Commvault

Commvault supports Azure SQL protection with flexible, long-term retention and stores backups separately from production in the customer’s chosen region, cloud, or Commvault-managed Air Gap Protect for immutable, compliance-focused copies.

Starting with Service Pack 40, Commvaultlimits export-based protection for Azure SQL databases up to 2 TB by default. This limit ensures stable, predictable performance for medium-sized databases and aligns with Microsoft best practices, as export operations for very large databases may not complete in a timely or consistent manner.

Adjusting the Export Threshold

For large Azure SQL databases above the 2 TB threshold, administrators can adjust the nAzureSQLDBMaxSizeForExportInGB setting on the relevant access node to define a higher export threshold.

Outcomes may vary depending on how Azure SQLPackage APIs process large datasets and complex schemas. Databases larger than 2 TB may not export in a timely fashion, potentially causing backup jobs to fail.

In such cases, Commvault recommends using Azure Native SQL backups, which are better suited for short-term recovery needs and operational resilience.

Performance Configuration Recommendations

You can improve the performance of Azure SQL database backup and restore operations by considering the following configuration recommendations.

Resource Allocation

Provision the Azure SQL Database service with a minimum of four vCores for optimal backup performance.
Use a Business Critical or Premium tier database for best performance.
Upgrade the service tier if the database has reached its resource limits. For more information, see Dynamically scale database resources with minimal downtime - Azure SQL Database & Azure SQL Managed Instance on the Azure SQL website.
Monitor database transaction unit (DTU) statistics in the Azure portal. This helps maintain visibility into performance impact during backup windows and supports proactive steps to avoid degradation to production workloads. For more information, see Azure SQL Database and Azure SQL Managed Instance resource monitoring on the Azure SQL website.

Restore Tier Selection

When restoring an SQL database to Azure, you can choose the database pricing tier that meets your performance requirements.

In the Advanced Options section of the Restore window, select the database tier.

If no pricing tier is selected, Pricing Tier Standard S0 is applied to the restored database by default.

Access Node and Networking Configuration

Run backups using an access node in the same region as the database to avoid performance issues caused by network latency.
Enable accelerated networking in the VM. For more information, see Accelerated Networking overview on the Azure SQL website.
If possible, use Redirect as the server connection policy. For more information, see Connection policy on the Azure SQL website.
If possible, use a Linux-based access node. Performance testing shows improved backup throughput when using Linux access nodes compared to Windows access nodes.

Staging Disk Configuration

Use staging disk space on SSD disks on the access node when backing up large databases.

When staging disk space is configured, the Microsoft SQL Server Data-Tier Application Framework (DacFx) is used to back up the databases. This provides the following advantages:

Allows backups of larger databases, with .bacpac file sizes greater than 200 GB.
The Allow Azure services and resources to access this server option is not required when the access node and the Azure SQL server are deployed in the same Azure tenant.

If you use Commvault Hosted Infrastructure to protect Azure SQL PaaS databases, this option must be enabled. In this configuration, the Commvault access node and the Azure SQL server are deployed in different Azure tenants, and this setting is required to allow connectivity.

Blob storage does not need to be associated with each Azure SQL instance because blob storage is no longer used for staging.

Microsoft does not provide a specific formula to calculate the disk space needed for staging .bacpac and temporary files. Disk requirements depend on database structure and data types. In some cases, staging disk space may need to be up to three times the size of the database.