Deploying Recovery Vault and setting tags for AzureBackupRG which is automatically created #3488
-
|
Hi, we are currently running into an issue when deploying Recovery Vaults(RSVs). We can successfully deploy RSVs via Bicep with its identity, private endpoint and backup policies. The issue we have is that a RSV will automatically create a resource group to house snapshots, unfortunately it seems the properties of this resource group cannot be controlled at deployment time, as a result, our policy blocks the creation of this resource group. (Tagging Policy sent to deny, without required tags deployment will fail). This causes backups to fail since there is no resource group to store the snapshots. As a result, we have to turn off our tagging policy, reset the backup and the resource group gets created (without tags) and the backup successfully starts. Has anyone ran into this issue before, turning off our tagging policy works for now but isnt very scalable.
Seems you can control the name but not really the 'resource group'. Ideally I would like to control the name and tags for this resource group. Has anyone ran into this? https://azure.microsoft.com/en-us/updates/azurebackuprg/ It also seems the docs are perhaps not up to date and do not show the instantRPDetails property: I am using 2021-03-01 for the bicep module. Thank you! |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
|
Unfortunately, there is not much from the bicep side that we can do. This is a result of the RSV resource provider. I'd recommend opening a support case to triage the request so the team is aware of it. Considering they have this |
Beta Was this translation helpful? Give feedback.
Unfortunately, there is not much from the bicep side that we can do. This is a result of the RSV resource provider. I'd recommend opening a support case to triage the request so the team is aware of it. Considering they have this
azureBackupRGNamePrefixproperty, they are likely aware of the problem, but they have may more info to share.