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
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
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: |
Restore pre-checks
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: |
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.
