Azure Backup: Unable to delete Recovery Services vault due to existing Azure Site Recovery dependencies

Question

Azure Backup: Unable to delete Recovery Services vault due to existing Azure Site Recovery dependencies

Koudelia Nikolai (Futurice) 0

Problem description

I am trying to delete a Recovery Services vault in Azure Backup, but the operation fails with the error code 'BMSUserErrorVaultDeletionNotAllowed'. The error indicates that the vault still contains an existing resource, specifically a SQL-related item associated with the vault. Despite reviewing the vault in the Azure portal, I see no backup items or backup infrastructure entries, and the counts are zero. I also attempted to delete the vault using Azure CLI, but it still reports dependencies related to a SQL workload, particularly 'Sql;htfakturahotelldev-rg;htfhsqltest01'. I have already verified that there are no visible backup items, infrastructure entries, or soft-deleted items, and there are no private endpoints or resource locks on the vault.

Environment

Azure Backup with a Recovery Services vault in an unspecified region. The delete attempt was performed using Azure CLI with the command 'az backup vault delete --name {vault-name} --resource-group {resource-group} --yes'. The vault appears empty in the portal, but the error points to a SQL workload dependency.

What I've already tried

I reviewed the vault in the Azure portal and confirmed that there are no visible backup items or infrastructure entries, with counts showing zero. I also attempted to delete the vault through Azure CLI, which failed with the 'BMSUserErrorVaultDeletionNotAllowed' error, referencing a SQL-related resource. I verified that there are no soft-deleted items, private endpoints, or resource locks on the vault. Additionally, I ran commands to list Azure workload containers and backup items, which returned empty lists, indicating no visible backup objects. I suspect there might be a hidden or stale SQL workload registration still attached to the vault, which is preventing deletion.

Current status

I am seeking guidance on how to identify and remove any hidden or stale SQL workload dependencies attached to the vault so that I can successfully delete the Recovery Services vault.

VEMULA SRISAI 14,075 Reputation points Microsoft External Staff Moderator

2026-10-16T16:41:17.4333333+00:00
Hello Koudelia Nikolai (Futurice),

Thank you for the detailed troubleshooting steps confirming zero backup items, zero infrastructure entries, no soft-deleted items, no private endpoints, and no resource locks rules out the common causes and points to a stale backend registration.

The BMSUserErrorVaultDeletionNotAllowed error referencing Sql;htfakturahotelldev-rg;htfhsqltest01 indicates that while the backup item itself has been removed, the container/protectable-item** **registration for that SQL instance is still present in the backend metadata store. This registration layer is tracked independently of what the Backup Items and Backup Infrastructure blades display, which is why the portal shows zero items even though the dependency check still finds it.

Before this needs backend involvement, please try unregistering the container directly:

az

This acts on the container record itself rather than on visible backup items, so it can succeed even when the item list is empty.

If this command also fails (for example, with a service/internal error), the container registration is orphaned at the backend and will need a backend metadata cleanup this isn't something that can be resolved from the portal, CLI, or REST API at that point.

Could you share the exact error returned by the unregister command, along with the operation's correlation ID from the Activity Log? That will let us confirm whether this needs to be routed for backend cleanup.

1 answer

Your answer

VEMULA SRISAI 14,075 Reputation points Microsoft External Staff Moderator

2026-10-16T16:41:17.4333333+00:00

Hello Koudelia Nikolai (Futurice),

Thank you for the detailed troubleshooting steps confirming zero backup items, zero infrastructure entries, no soft-deleted items, no private endpoints, and no resource locks rules out the common causes and points to a stale backend registration.

The BMSUserErrorVaultDeletionNotAllowed error referencing Sql;htfakturahotelldev-rg;htfhsqltest01 indicates that while the backup item itself has been removed, the container/protectable-item** **registration for that SQL instance is still present in the backend metadata store. This registration layer is tracked independently of what the Backup Items and Backup Infrastructure blades display, which is why the portal shows zero items even though the dependency check still finds it.

Before this needs backend involvement, please try unregistering the container directly:

az

This acts on the container record itself rather than on visible backup items, so it can succeed even when the item list is empty.

If this command also fails (for example, with a service/internal error), the container registration is orphaned at the backend and will need a backend metadata cleanup this isn't something that can be resolved from the portal, CLI, or REST API at that point.

Could you share the exact error returned by the unregister command, along with the operation's correlation ID from the Activity Log? That will let us confirm whether this needs to be routed for backend cleanup.

Answer 1

Hello @Koudelia Nikolai (Futurice)

Thanks for providing the detailed troubleshooting results.

Since you've already verified that the Recovery Services vault contains no visible backup items, registered infrastructure, soft-deleted items, private endpoints, or resource locks, I agree that repeating the standard vault cleanup steps is unlikely to help.

The important clue is the error: BMSUserErrorVaultDeletionNotAllowed

The deletion request still references: Sql;htfakturahotelldev-rg;htfhsqltest01

This suggests that Azure Backup still detects a SQL workload dependency, even though the corresponding resources aren't visible in the portal or your CLI queries.

Recommended next step

As the Microsoft moderator suggested, unregistering the SQL workload container is worth checking. However, since your earlier container-list commands returned empty results, first verify whether Azure PowerShell can discover the container.

Microsoft documents the following approach for retrieving SQL workload containers:

$vault = Get-AzRecoveryServicesVault `
    -ResourceGroupName "<resource-group>" `
    -Name "<vault-name>"
$containers = Get-AzRecoveryServicesBackupContainer `
    -ContainerType AzureVMAppContainer `
    -BackupManagementType AzureWorkload `
    -VaultId $vault.ID
$containers | Format-List Name, FriendlyName, ContainerType

If the affected SQL container appears, confirm that all associated protected data has already been removed before unregistering it.

The following cmdlet for unregister an existing container:

Unregister-AzRecoveryServicesBackupContainer `
    -Container $container `
    -VaultId $vault.ID

Here, $container must be the specific container object selected and verified from the preceding query.

Important: Unregistering a backup container changes its registration with the Recovery Services vault. Before proceeding, confirm that no protected SQL databases or recovery points need to be retained.

If the container is not returned

If Azure PowerShell also returns no matching SQL workload container, but vault deletion continues reporting the same dependency, stop attempting additional deletion or cleanup commands.

At that point, the available evidence suggests a possible inconsistency between the vault's visible resources and the dependencies detected during deletion.

However, we cannot conclusively identify an orphaned backend registration without Microsoft investigating the service-side metadata.

Microsoft Support investigation

I recommend opening an Azure Backup support request and providing:

Recovery Services vault name and resource ID.
Error code: BMSUserErrorVaultDeletionNotAllowed.
Referenced SQL workload: Sql;htfakturahotelldev-rg;htfhsqltest01.
Results of the Azure CLI and PowerShell container queries.
Failed deletion timestamp and correlation ID from the Azure Activity Log.

Ask Microsoft Support to verify whether a stale SQL workload registration or another internal dependency is preventing vault deletion.

I don't recommend bypassing the dependency checks through direct resource deletion requests or running automated vault cleanup scripts, particularly while the SQL registration state remains uncertain.

Could you confirm whether the Azure PowerShell query also returns no results, or whether it identifies the SQL workload container?

That distinction should help determine whether we can still use a documented unregistration procedure or whether Microsoft needs to investigate the remaining dependency.

Hope this helps narrow down the issue.

References:

Help make this community better for everyone: If this answer helped or resolved your issue, please accept it or upvote it. If not, share more details in a comment so we can continue the discussion and find the right solution. Thank you.