Unable to delete Azure Blob Backup Instance after Storage Account was deleted. Policy remains permanently referenced

Hello Fankhauser Silvio,

Greetings! Thanks for raising this question in the Q&A forum.

The root cause here is a permission-validation problem, not a data or governance bug. For Azure Blob Operational Backup, the Stop Protection and Delete Backup Instance operations both perform a real-time RBAC check against the protected resource itself (the storage account), because operational backup relies on the vault holding a role assignment (Storage Account Backup Contributor) directly on that storage account. Once the storage account is deleted, there's nothing left for Azure Backup to validate that role assignment against, so the check fails closed and you get UserErrorMissingRequiredPermissions, even though you have full Owner or Contributor rights on the vault itself. That also explains why Stop Protection separately fails with UserErrorInvalidBackupInstanceOperation: once the instance has already moved into ProtectionError because the source is gone, Stop Protection isn't a valid transition from that state, so you're caught between two operations that each fail for a different reason.

To your specific questions:

Is this expected behavior? It's a known limitation of Azure Blob Operational Backup rather than intended lifecycle design. Several other reports describe the same pattern: delete the storage account first, and the backup instance gets stuck referencing a resource that no longer exists, blocking both instance and policy deletion.

Supported cleanup process today:

• Try the Azure portal path first, since it sometimes resolves cases the CLI doesn't: Backup center > Vaults > [your vault] > Backup instances > select the stuck instance > Delete (skip Stop Protection since the instance is already in ProtectionError).
  • If that fails, try PowerShell instead of the CLI:

        $instance = Get-AzDataProtectionBackupInstance -ResourceGroupName "<vault-rg>" -VaultName "<vault-name>" | Where-Object { $_.Property.DataSourceInfo.ResourceId -like "*<deleted-storage-account-name>*" }Remove-AzDataProtectionBackupInstance -ResourceGroupName "<vault-rg>" -VaultName "<vault-name>" -Name $instance.Name -Force
  

  The PowerShell cmdlet's -Force path has, in other reported cases, succeeded where the CLI's az dataprotection backup-instance delete returned the same permissions error.

  - If both of those still return `UserErrorMissingRequiredPermissions`, that confirms the backend can't validate against the missing resource through any client path, and cleanup will need backend intervention (see escalation below).
  
  **Is it necessary to keep the Storage Account alive until the Backup Instance is removed?** Yes, that's the safe order of operations. Best practice is: Stop Protection (retaining backup data if you still need it) and, if desired, delete the Backup Instance, and only then delete the Storage Account. Once the storage account is gone first, you lose the clean path to remove the instance yourself.
  
  **Cleanup without a Support case:** Try steps 2 above first. If both the portal and PowerShell `-Force` attempts fail with the same permissions error, a Support case is currently the reliable route, since this is a backend metadata cleanup rather than something exposed through a documented client-side override.
  

If you do need to escalate, it'll go faster with:

• Subscription ID, Backup Vault name and resource group, and the Backup Instance name/resource ID
• The exact error code UserErrorMissingRequiredPermissions and the operation you ran (delete vs. stop-protection vs. ARM delete)
• Confirmation that the source storage account has already been deleted
• Correlation ID from the failed operation if you have one (visible in the Azure Activity Log entry for the failed request)

Route the case to the Azure Backup service team under a support plan that includes technical support (Developer tier or above); mention it's an orphaned Blob Operational Backup instance blocking policy deletion after source deletion, since this is a recognized pattern they can resolve on the backend.

If this answer helps you kindly accept the answer which will help others who have similar questions.

Best Regards,

Jerald Felix.