Like most Azure resources, Key Vaults have a built-in level of redundancy to mitigate catastrophic failure, like an Azure region going down. All Azure regions have a mirror region or pair where resources are automatically replicated as part of business continuity. This failover process is automatic and invisible to end users. Region pairing is not configurable; for the most part, paired regions are co-located within the same country. The stated reason for these pairings is proximity and other factors, presumably something like reduced latency and increased speed.

Looking at some of the pairings is food for thought in terms of region-wide failures. For instance, Japan and Norway are thin or narrow countries, so east-west region redundancy doesn't have the same level of isolation as, say, East US versus West US. Proximity and other factors are more about governance and jurisdiction. That is, the paired regions belong to the same security world. For the most part, security worlds are analogous to countries, except for Ireland and the Netherlands, that fall under EU jurisdiction. You can back up and restore key vault resources, but you must follow paired region constraints, backing up and restoring within a security world.

So what do these constraints mean in practical terms? There is no valid way to back up a whole key vault as a single entity. Microsoft has this rather ominous paragraph in Azure Key Vault backup and restore documentation, alluding that it may be possible to back up an entire vault with Azure CLI commands, but it is far from recommended. Other considerations and limitations include; you can't back up more than 500 past versions of certificates, keys, or secrets. Backing up secrets with multiple versions may cause time-out errors, and if there are many versions, you may exceed vault service limits causing throttling and resulting in the backup failing. A vault resource is backed up as a blob file, which can only be restored to a vault in the same geographic region, i.e., security world.

Let's back up the connection string secret by clicking on the secret and selecting download backup. I'll download it onto my PC and then delete the secret from the vault. I want to restore to the same vault to show you some minor issues to look out for. The connection secret is gone, and we're back on the secret's main page. Now I'll restore the backup, selecting it from my PC. Ok, the first issue is not a timing one, as in, I'm performing these operations too quickly, but it is caused by purge protection.

While the secret is no longer visible in the vault, it still exists. I need to purge it completely. I can do that through manage deleted secrets, or so I thought, being the vault owner. This vault is set up to use access policies, and the purge permission wasn't set by default when I created the vault. I'll go into access policies, select the user, click edit, and check purge permission on secrets. Then Click next and save. Right, back to manage deleted secrets, and the purge button is enabled. After confirming the purge, we can complete the restore operation successfully.