Currently this is
AzureBackupRG_<Geo>_<number>
But this creates resource groups that conflict with our Resource Group naming convention.
⚠Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.
@masterbacon Thanks for the feedback! I have assigned the issue to the content author to evaluate and update as appropriate.
Agreed with @masterbacon - there needs to be way to specify the name of this resource group to ensure consistency with user defined naming conventions.
Also, is this something that has changed recently? As I implemented Azure Backup jobs earlier this year and I don't recall seeing this Resource Group appear?
@Adam-Smith-MSFT please assign to me
Same issue, this RG seems to be created when we add a vm to backup...
What is the goal of this RG ? It didn't appear on my previous Recovery Services Vault created few months ago.
This is called out in the article . It's used to store restore points.
Note
Backup service creates a separate resource group than the resource group of the VM to store restore point collection. Customers are advised not to lock the resource group created for use by the Backup service. The naming format of the resource group created by Backup service is: AzureBackupRG_
Eg: AzureBackupRG_northeurope_1
Thanks! #please-close
This is called out in the article . It's used to store restore points.
NoteBackup service creates a separate resource group than the resource group of the VM to store restore point collection. Customers are advised not to lock the resource group created for use by the Backup service. The naming format of the resource group created by Backup service is: AzureBackupRG__
Eg: AzureBackupRG_northeurope_1Thanks! #please-close
The problem that we are facing with this ResourceGroup is that, if we have enabled the policy "Deny resource deplpoyment without tags", the RG is created but because of this policy, I am assuming the snapshots are not being created as they cant be tagged and the backup of Azure VM fails. Any way to work around this ?
The problem that we are facing with this ResourceGroup is that, if we have enabled the policy "Deny resource deplpoyment without tags", the RG is created but because of this policy, I am assuming the snapshots are not being created as they cant be tagged and the backup of Azure VM fails. Any way to work around this ?
You may exclude the specific Resource Group from your policy to work around this issue.
Agreed with @masterbacon. Auto-generated and non-changable naming schemes should not be forced into the environment. Doesn't play well with tagging, azure policy, or resource locking. If this is a required back-end service, then hide it from the customer.
+1
We shouldn't have these resource groups forced in the environments. Especially when they cannot be renamed to fit naming conventions, and when we have to adjust our existing policies just to allow the backups to work.
Currently, there is no way of naming the Azure Backup RG. All the RGs have the naming format AzureBackupRG_geography_number (example: AzureBackupRG_northeurope_1).
We've passed on your suggestion to the development team. Thanks for your contribution!
As a customer there is nothing we can do about that resource group and excluding it from the policy is not a workaround when our expectation is to follow the company's naming convention and being compliant with the policies. I don't think the product was released with due diligence and testing when there are so many issues with it because lately I am hitting an iSCSI issue for which there is an open case already with MS and they have been collecting dumps with no result so far.
Please continue to reconsider this design constraint in your model. If it is best practice to store the restore point collection in a different RG, then please allow this to be a configurable item.
Currently No, the naming convention is fixed for RG created by Azure Backup service. We are releasing an update to this in a week where user can update the RG name as per his requirement from the backup policy blade.
+1, every single enterprise has naming standards that are enforced. Not having configurable resource groups breaks governance models
Most helpful comment
Agreed with @masterbacon. Auto-generated and non-changable naming schemes should not be forced into the environment. Doesn't play well with tagging, azure policy, or resource locking. If this is a required back-end service, then hide it from the customer.