Problem description
After an Azure SQL backup job completes successfully, the transient QuantumBridge VM remains in a running state within the customer's Azure subscription instead of being automatically provisioned out and deleted.
This behavior results in an orphaned cloud resource that continues to run indefinitely, leading to unnecessary and unexpected compute infrastructure charges on the customer's Azure billing statement.
Cause
At the conclusion of an Azure SQL backup workflow, Druva initiates an automated VM self-deletion command through the Azure ARM API using the assigned Managed Identity credentials.
An orphaned VM occurs when this workflow breaks down:
Primary Cleanup Failure: The initial self-deletion command fails due to issues such as missing Azure permissions on the Managed Identity, API throttling by Azure, or silent gateway timeouts.
Fallback Cleanup Failure: The Druva Provisioning Service subsequently attempts a secondary fallback cleanup operation. If this fallback mechanism also encounters API blocks or policy restrictions, the cleanup completely fails, leaving the
DruvaQuantumBridgeVM running in a stranded state.
Resolution
Follow these sequential troubleshooting and remediation steps to resolve the issue:
Verify Job Status:
Log in to the Druva Management Console.
Navigate to Protect > Azure > Azure SQL > All Jobs.
Confirm that no backup or restore operations are currently in progress for the associated SQL instances.
Isolate and Manually Delete Orphaned Resources:
Log in to the Azure Portal and navigate to the relevant Resource Group.
Locate any active
DruvaQuantumBridgeVMs.If step 1 confirmed that no jobs are running, manually Delete the orphaned VM.
Ensure you also select and delete associated ephemeral resources (such as the Network Interface card [NIC] and OS disk) if they were not automatically cleaned up.
Audit Azure Permissions & Identity Access:
Go to the Activity Log of the target Resource Group to audit the failed deletion operations.
Verify that the Managed Identity assigned to the QuantumBridge environment explicitly possesses the
Microsoft.Compute/virtualMachines/deletepermission on that specific Resource Group.
Review Azure Governance Policies:
Check if any active Azure Policies (e.g., resource lock downs, delete restrictions, or mandatory tagging constraints) are blocking resource deletion workflows inside the target subscription or scope.
Validate Resolution:
Retrigger a manual backup job from the Druva Management Console.
Monitor the Azure Portal to verify that a new QuantumBridge VM deploys dynamically and terminates successfully upon job completion.
š Need Assistance? If the cleanup continues to fail or Azure permissions are verified as correct, collect your exported Azure Activity Log entries showing the failed delete operations and open a ticket with Druva Support.
Include and exclude filters
Include Filters: This issue applies specifically to Azure SQL workloads (Azure SQL Database, Managed Instances, or SQL Server on Azure VMs) using the ephemeral Isolated Copy protection feature.
Exclude Filters: This does not impact standard file-level backups, native AWS workloads, or environments where backups are processed without deploying on-demand Azure QuantumBridge virtual machine nodes.
Verification
To verify that your configuration is completely fixed:
Launch a manual backup or pre-check job via the console.
Observe the creation of the
DruvaQuantumBridgeinstance in the Azure Portal.Wait for the job status to transition to Successful under All Jobs > Azure SQL.
Refresh your Azure Resource Group to ensure the VM and its network/storage interfaces disappear within minutes of job finalization.