To ensure reliable and predictable data protection, Druva’s built-in prechecks validate your Azure SQL resources against core prerequisites before backup or restore operations. These automated checks proactively detect incorrect credentials and network misconfigurations—such as missing VNet rules or non-delegated subnets. By identifying these issues early, the system provides clear error codes and specific solutions, significantly reducing the likelihood of subsequent job failures.
Authentication Prechecks
Before you trigger your first backup, use these pre-checks to ensure Druva has the necessary connectivity and permissions to protect your data. Identifying gaps now prevents job failures and ensures a seamless onboarding experience.
The pre-checks apply to Azure SQL database, SQL Managed Instance, and SQL Server on Azure VM.
Pre-check | Description | Recommended Action |
SQL Server Credential Check | Verifies whether the provided authentication credentials are valid. | For Service Principal, make sure you have mapped the concerned admin (as per your organization in the Management Console) for your Azure SQL resource. For more information, see How to map service principal in Azure. For SQL authentication, validate the authentication credentials provided by your database administrator and reassign the authentication with the correct authentication credentials. For more information, see Assign Authentication. |
VNet Rule Check | This check ensures that the database is configured with a VNet rule permitting inbound network connection from the specific virtual network where the Quantum Bridge VMs are deployed. | No VNet rule that allows Druva to connect to the database is found. Configure a VNet rule for the database. For more information, see Pre-requisites for protecting Azure SQL resources. |
Subnet Check | This check ensures the subnet is configured, is non-delegated, and is not used by the following Azure built-in services:
| Configure a non-delegated subnet in the virtual network associated with the Azure SQL Managed Instance. Also, ensure it is not used by the Azure built-in services. For more information, see Pre-requisites for protecting Azure SQL resources. |
Inbound port check | Validate that the Network Security Group (NSG) associated with the Azure SQL Managed Instance delegated subnet includes an inbound security rule allowing traffic on TCP port 1433. This ensures connectivity to the VNet-local endpoint via the default Redirect connection policy. | Update the Network Security Group (NSG) rules for the Azure SQL Managed Instance delegated subnet to permit inbound traffic on TCP port 1433. For step-by-step instructions on configuring the security rules to allow application-tier connectivity, see Configure NSG for Azure SQL Managed Instance. |
Outbound Check | Verifies outbound connectivity from the Azure SQL Managed Instance subnet (on which the Druva Quantum Bridge is spawned) to the Azure Key Vault service over TCP port 443. | Update the Network Security Group (NSG) rules and User-Defined Routes (UDR) for the Azure SQL Managed Instance subnet (on which the Druva Quantum Bridge is spawned) to permit outbound traffic to the Azure Key Vault service on TCP port 443. Connectivity must be verified for both the primary and secondary (failover) Key Vaults to ensure high availability of the encryption protector. This requirement applies regardless of the endpoint type being used:
For step-by-step configuration and a list of all required outbound rules, see |
Backup pre-checks
As the final step before creating a backup set, Druva performs automated validations to ensure your environment is fully prepared. These pre-checks identify connectivity issues, permission gaps, or unsupported configurations that must be resolved to complete the configuration. By blocking the finalization of invalid setups, Druva prevents immediate backup failures.
Pre-check | Description | Recommended Action |
SQL Server Credential Check | Verifies whether the provided authentication credentials are valid. | For Service Principal, make sure you have mapped the concerned admin (as per your organization in the Management Console) for your Azure SQL resource. For more information, see How to map service principal in Azure. For SQL authentication, validate the authentication credentials provided by your database administrator are still valid, and if changed, reassign the authentication with the correct authentication credentials. For more information, see Assign Authentication. |
VNet Rule Check | This check ensures that the database is configured with a VNet rule permitting inbound network connection from the specific virtual network where the Quantum Bridge VMs are deployed.
| No VNet rule that allows Druva to connect to the database is found. Configure a VNet rule for the database. For more information, see Pre-requisites for protecting Azure SQL resources. |
Subnet Check | This check ensures the subnet is configured, is non-delegated, and is not used by the following Azure built-in services:
| Configure a non-delegated subnet in the virtual network associated with the Azure SQL Managed Instance. Also, ensure it is not used by the Azure built-in services. For more information, seePre-requisites for protecting Azure SQL resources. |
Inbound port check | Validate that the Network Security Group (NSG) associated with the Azure SQL Managed Instance delegated subnet includes an inbound security rule allowing traffic on TCP port 1433. This ensures connectivity to the VNet-local endpoint via the default Redirect connection policy. | Update the Network Security Group (NSG) rules for the Azure SQL Managed Instance delegated subnet to permit inbound traffic on TCP port 1433. For step-by-step instructions on configuring the security rules to allow application-tier connectivity, refer to the official guide: Configure NSG for Azure SQL Managed Instance. |
Outbound Check | Verifies outbound connectivity from the Azure SQL Managed Instance subnet (on which the Druva Quantum Bridge is spawned) to the Azure Key Vault service over TCP port 443. | Update the Network Security Group (NSG) rules and User-Defined Routes (UDR) for the Azure SQL Managed Instance subnet (on which the Druva Quantum Bridge is spawned) to permit outbound traffic to the Azure Key Vault service on TCP port 443. Connectivity must be verified for both the primary and secondary (failover) Key Vaults to ensure high availability of the encryption protector. This requirement applies regardless of the endpoint type being used:
For step-by-step configuration and a list of all required outbound rules, refer to the official Microsoft documentation: |
Database Owner Permission Check
Applies to Azure SQL Database, SQL Managed Instance, and SQL Server on Azure VM.
| This check runs at the database level to verify that the SQL credential (or the Entra ID administrator) is assigned the db_owner role for all databases in the backup set. | Grant the |
Sysadmin Permission Check
Applies to SQL Managed Instance and SQL Server on Azure VM. | Verifies that the SQL credential (or the Entra ID administrator) is assigned the | Grant the |
User table check
Applies to Azure SQL database, SQL Managed Instance, and SQL Server on Azure VM. | Verifies if user-created tables exist in the databases (e.g., d1, d2...). | Check if the databases are intentionally empty. If they should contain tables, add them. Otherwise, if they are not needed for backup, exclude them from the backup set. |
SQL Server Agent Check
Applies to SQL Server on Azure VM. | Verifies if the SQL Server Agent is running on the target VM. This is required to finalize the restore and manage post-recovery tasks. | Start the SQL Server Agent service on the target VM and ensure the Startup Type is set to Automatic. |
Unsupported Table Type Check
Applies to Azure SQL database, SQL Managed Instance, and SQL Server on Azure VM. | Verifies if the table types in the database(s) are supported. | Review the databases and identify tables with unsupported types. Migrate data to supported table types or exclude these databases from backup. |
Change Data Capture (CDC) Configuration Check
Applies to Azure SQL database, SQL Managed Instance, and SQL Server on Azure VM. | Verifies if CDC is enabled at the database level, table level, and column level. | Review the CDC configuration for the affected databases. Ensure CDC is enabled at the database level, the CDC schema exists, all required tables are tracked, and columns are configured. |
Database Status Check
Applies to Azure SQL database, SQL Managed Instance, and SQL Server on Azure VM. | Verifies if all databases in the backup set are in an Online state. | Bring the databases online by resolving any underlying issues. |
Unsupported Character Check.
Applies to Azure SQL database, SQL Managed Instance, and SQL Server on Azure VM. | Verifies if the database name has a semicolon ‘;’. | Provide a database name that does not contain a semicolon ‘;’. |
CDC Job Parameter Check
Applies to Azure SQL database, SQL Managed Instance, and SQL Server on Azure VM. | Verifies if CDC-enabled databases have cleanup and capture job parameters that meet Druva’s requirements. | Review and adjust the CDC capture and cleanup job parameters to ensure they match Druva’s requirements. For more information, see Pre-requisites for protecting Azure SQL resources. |
Restore pre-checks
As the final step before initiating a recovery, Druva runs automated validations on the target environment to ensure it is ready to host the restored data. These checks serve as a safety gate to prevent accidental overwrites and identify issues—such as duplicate database names or unsupported characters—that would cause the restore to fail. You must resolve all identified conflicts before the restore operation can proceed.
Pre-check | Description | Recommended Action |
SQL Server Credential Check | Verifies whether the provided authentication credentials are valid. | For Service Principal, make sure you have mapped the concerned admin (as per your organization in the Management Console) for your Azure SQL resource. For more information, see How to map service principal in Azure. For SQL authentication, validate the authentication credentials provided by your database administrator are still valid, and if changed, reassign the authentication with the correct authentication credentials. For more information, see Assign Authentication. |
VNet Rule Check | This check ensures that the database is configured with a VNet rule permitting inbound network connection from the specific virtual network where the Quantum Bridge VMs are deployed.
| No VNet rule that allows Druva to connect to the database is found. Configure a VNet rule for the database. For more information, see Pre-requisites for protecting Azure SQL resources. |
Subnet Check | This check ensures the subnet is configured, is non-delegated, and is not used by the following Azure built-in services:
| Configure a non-delegated subnet in the virtual network associated with the Azure SQL Managed Instance. Also, ensure it is not used by the Azure built-in services. For more information, seePre-requisites for protecting Azure SQL resources. |
Inbound port check | Validate that the Network Security Group (NSG) associated with the Azure SQL Managed Instance delegated subnet includes an inbound security rule allowing traffic on TCP port 1433. This ensures connectivity to the VNet-local endpoint via the default Redirect connection policy. | Update the Network Security Group (NSG) rules for the Azure SQL Managed Instance delegated subnet to permit inbound traffic on TCP port 1433. For step-by-step instructions on configuring the security rules to allow application-tier connectivity, refer to the official guide: Configure NSG for Azure SQL Managed Instance. |
Outbound Check | Verifies outbound connectivity from the Azure SQL Managed Instance subnet (on which the Druva Quantum Bridge is spawned) to the Azure Key Vault service over TCP port 443. | Update the Network Security Group (NSG) rules and User-Defined Routes (UDR) for the Azure SQL Managed Instance subnet (on which the Druva Quantum Bridge is spawned) to permit outbound traffic to the Azure Key Vault service on TCP port 443. Connectivity must be verified for both the primary and secondary (failover) Key Vaults to ensure high availability of the encryption protector. This requirement applies regardless of the endpoint type being used:
For step-by-step configuration and a list of all required outbound rules, refer to the official Microsoft documentation: |
SQL Server Agent Check
Applies to SQL Server on Azure VM. | Verifies if the SQL Server Agent is running on the target VM. This is required to finalize the restore and manage post-recovery tasks. | Start the SQL Server Agent service on the target VM and ensure the Startup Type is set to Automatic. |
Duplicate Database Name Check
Applies to Azure SQL database, SQL Managed Instance, and SQL Server on Azure VM. | Verifies if a database with the same name already exists on the target SQL Server instance or logical server. | To avoid overwriting existing data, provide a unique name for the restored database (e.g., DBName_Restored) or delete the existing database if it is no longer required. |
Unsupported Character Check
Applies to Azure SQL database, SQL Managed Instance, and SQL Server on Azure VM. | Verifies if the database name contains a semicolon ‘;’. | Provide the database name that does not contain a semicolon ‘;’. |
Steps to identify the subnet on which the Quantum Bridge is spawned
For each backup or restore job request, Druva creates a virtual machine called Druva Quantum Bridge within the customer's Azure environment. This bridge facilitates communication between the SQL resource being protected and Druva Cloud Storage.
This section helps identify the subnet in which the Druva Quantum Bridge is spawned.
Make sure the Network Security Group (NSG) rules for this subnet permits inbound/outbound traffic on TCP port 1433.
Scenario 1: Azure SQL with Private Link (Private Endpoints)
Azure SQL Database
When Private Endpoints are in use, the Quantum Bridge VM is spawned in the subnet associated with the private endpoint.
Log in to the Azure Console.
In your Azure SQL database server settings, navigate to Security > Networking.
Locate the list of Private Endpoints.
The system selects one endpoint from this list. Identify the Virtual Network (VNet) and Subnet associated with this private endpoint. The Quantum Bridge VM will spawn here.
Azure SQL Managed Instance
When Private Endpoints are configured, the Quantum Bridge VM is spawned in the subnet associated with the private endpoint.
Log in to the Azure Console.
In your Azure SQL Managed Instance settings, navigate to Security > Networking.
Locate the list of Private Endpoints.
The system selects one endpoint from this list.
Identify the Virtual Network (VNet) and Subnet associated with that private endpoint. The Quantum Bridge VM will spawn here.
Scenario 2: Azure SQL with Service Endpoints
Azure SQL Database
Log in to the Azure Console.
In your Azure SQL database server settings, navigate to Security > Networking.
In the right pane, a list of Vnet rules is displayed. One of these rules is selected.
The Druva Quantum Bridge VM is spawned on the VNet/Subnet associated with that VNet rule.
Azure SQL Managed Instance
For Azure SQL Managed Instance, only one VNet is associated with each Managed Instance. The VNet might have multiple subnets.
Log in to the Azure Console.
In your Azure SQL Managed Instance, in the right pane, navigate to the Virtual Network associated with the Managed Instance.
Review the list of subnets within that VNet.
The Quantum Bridge is spawned within a subnet of this VNet that satisfies the following criteria:
The subnet has a pre-defined name — Druva-QuantumBridge-Subnet (optional).The subnet is non-delegated
The subnet is not used by the following Azure built-in services:
GatewaySubnet
AzureFirewallSubnet
AzureBastionSubnet
AzureFirewallManagementSubnet
RouteServerSubnet
If the predefined name is not found, it looks for a subnet that is non-delegated and non-reserved by the above Azure built-in services.
SQL Server on Azure VMs
For SQL Server running on an Azure Virtual Machine, the Quantum Bridge VM is spawned in the same subnet as the SQL Server VM.
Log in to the Azure Console.
Navigate to the SQL Server VM resource in the Azure Portal.
Go to Networking settings.
On the right pane, note the Subnet listed for that interface.
The Quantum Bridge VM will be spawned in this exact subnet.
