A client could not delete what I called an Azure Key Vault at the time. The portal said there were still resources inside it. I found a PowerShell script that emptied it, and the vault was gone. Reading this post again years later, I found three things to correct: the kind of vault it was, the module the script used, and a rule that now blocks deletion for two weeks.
The Error
Vault deletion error
Vault 'ProdRecoveryVault' cannot be deleted as there are existing resources within
the vault. Please delete any replicated items, registered servers, Hyper-V sites
(Used for Site Recovery), policy associations for System Center VMM clouds
(Used for Site Recovery) and then delete the vault.Correction One: It Was Not a Key Vault
I called it an Azure Key Vault in the title, and the title stays so old links keep working. But it was not one. A Key Vault stores secrets, keys and certificates. This was a Recovery Services vault, which stores backups. The error message gives it away: replicated items, registered servers, Site Recovery. None of those live in a Key Vault.
The difference matters, because the fixes are completely different. If you have landed here with a Key Vault that will not delete, this post is not your answer.
What Was Inside
The vault still held long-term retention backups of Azure SQL databases. Those are backup items, and a Recovery Services vault refuses to be deleted while it has any. The script I used at the time did three things: stop protection on each item and delete its recovery points, unregister each container, then delete the vault.
Correction Two: That Script Uses a Retired Module
The original script was written with AzureRM cmdlets, the ones with names like Get-AzureRmRecoveryServicesVault. Microsoft’s documentation says AzureRM was deprecated on 29 February 2024. It may still run, but it is no longer maintained or supported. The replacement is the Az module, where the names drop the “Rm”.
There is a second problem. The old script asked for containers of type AzureSQL. I checked the current reference for Get-AzRecoveryServicesBackupContainer, and its container type now accepts AzureVM, AzureStorage, AzureWorkload and MAB. AzureSQL is not on the list. So the old script would fail at that line today, and I am not going to hand you a rewritten version that I cannot run.
What I can give you is the shape of it, with the Az cmdlets whose parameters I checked in Microsoft’s current documentation:
Disable-AzRecoveryServicesBackupProtection -Item <item> -RemoveRecoveryPoints -VaultId <vault id>
Unregister-AzRecoveryServicesBackupContainer -Container <container> -VaultId <vault id>
Remove-AzRecoveryServicesVault -Vault <vault>I do not have an Azure subscription wired to my test machine, and the Az module is not installed here, so I have not run any of these. For a one-off job like this, the Azure portal is usually the safer route anyway: open the vault, go to Backup items, stop backup for each one with the option to delete backup data, and the portal walks you through the rest.
Correction Three: The Two-Week Wait
This is the one that catches people today. Azure Backup now has soft delete. When you delete backup data, the items are not removed at once. They are kept in a soft-deleted state, so a mistake or an attacker cannot wipe your backups in one click.
Microsoft’s documentation on deleting a vault is clear about the consequence. A vault cannot be deleted while it holds soft-deleted items, and those items are only removed for good 14 days after the delete. So you can do everything right, empty the vault completely, and still get told it is not empty.
You have two choices. Wait the 14 days. Or, if you are certain, follow Microsoft’s documented steps. In the vault, go to Properties, then Security Settings, and turn off soft delete. Then find the items still in the soft-deleted state, restore them, and delete them again. With soft delete off, that second delete is permanent. It is quicker than waiting. It also removes the protection soft delete exists to give you, so make sure nobody needs those backups. If the vault has extra security features switched on, you may need your security administrator’s permission first.
What I Would Check First
Open the vault in the portal and look at Backup items and Backup infrastructure. Anything listed there is what is holding the vault. If both look empty and deletion still fails, look for items in the soft-deleted state. That is the most likely answer today.
And before you delete a vault that held database backups, be sure nothing still depends on them. Long-term retention backups are usually kept for a reason, often a legal one. Deleting a vault is quick. Explaining why seven years of monthly backups are gone is not.
This error is not the vault being stubborn, it is the vault still holding backups, sometimes for fourteen more days.
This post was rewritten in September 2026. It was first published on 16 October 2018.
Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.
