Open schweikert opened 5 years ago
Is this fixed ? This is blocking . We want to create LRS RSV(s) and not GRS , which we are unable to do now . Please let us know.
Same here!
Is this fixed ? This is blocking . We want to create LRS RSV(s) and not GRS , which we are unable to do now . Please let us know
I'd like to chime in on this too. I have a requirement to keep all data locally so need the RSV set to LRS. At the moment, I need to create the RSV, manually set LRS, then run VM enrollment separately.
Is there any reaction to this or does anyone have an idea?
As of now, you can only create vaults with GRS and then immediately update it with LRS. Once any backup items are protected, you CANNOT change this value.
please-close
why close! dont close! this is ridic, how you will code this? that destroys the meaning of automation and infrastructure as a code
Any chance to reconsider this ticket's closure?
please-close
Yes, We cannot close it. you need to fix it, else it destroys the meaning of automation!
Could anyone tell me, what value should i out in SKU : "" property to set as LRS in recovery Services Vault, as I see RS0 is not working.
. Status=400 Code="InvalidRestApiParameter" Message="sku parameter is invalid.\r\nPlease provide a valid sku"
Could anyone tell me, what value should i out in SKU : "" property to set as LRS in recovery Services Vault, as I see RS0 is not working.
. Status=400 Code="InvalidRestApiParameter" Message="sku parameter is invalid.\r\nPlease provide a valid sku"
You can only set it to "Standard" for GRS. This is literally the whole point of why this issue was raised.
the only way we found so far is
once you have created the tersor, but before first backup, you can change it via Powershell
Get-AzRecoveryServicesVault -Name "
Has this issue been fixed ?
ABerTSC , Will terraform not try to change it to GRS on next run as per the input config ?
@turjachaudhuri, I created a vault, manually flipped to LRS, then re-ran apply. TF did not detect the change to LRS and did not try to flip it over.
However, you cannot set the vault to LRS after you onboard a client, essentially making onboarding a VM automatically (or any other service) into RSV completely worthless using terraform. So right now it's GRS or bust that I can see.
I'm also currently having an issue with this, and it's blocking a full IAC transition from ARM JSON to Terraform. As this is a business continuity/disaster recovery resource, please consider bumping this issue up in priority. Somebody initially reported this issue about two years ago in 2018, and it is now nearing the final quarter of 2020. We love this product; let's iron out this bug!
Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @Sharmistha-Rai.
It has been almost 2 years since this was first reported. Has any progress been made on this?
There is a fundamental misunderstanding here. In order to update storage redundancy of the vault, SKU is NOT the right parameter. It is storageType and this API is required to be called. However, this API should be called immediately after vault creation and this value cannot be changed once any backup item is protected. So, the sequence of calls is 1) Create vault (PUT API) 2) Update storage config (PUT API) 3) Configure backups (PUT API).
Hope this helps in automation sequence.
The original reason why this issue was raised is because azurerm_recovery_services_vault resource used in Terraform cannot specify RS0 for local storage because the API returns that the SKU is invalid (see the first post).
But RS0 is not required for local storage. As I see, the comment was: "RS0 seems to be undocumented by Microsoft, but looking at the generated ARM template it seems to be what you need to set if you want LRS storage for the backups (instead of the default GRS)." This is not the case. You don't need to set the SKU to RS0 to set the value to local storage. By default, all vaults will be created by GRS (there is no choice here, as of now). So, you have to create the vault and then call the PUT API to update the storage redundancy configuration from GRS to LRS.
Hope this helps.
Hope this helps.
Deploy RSV for my firm and have same problem: Failure responding to request: StatusCode=400 -- Original Error: autorest/azure: Service returned an error. Status=400 Code="InvalidRestApiParameter" Message="sku parameter is invalid.\r\nPlease provide a valid sku"
Refer to documentation: https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/resources/recovery_services_vault I can see that RS0 is supported. I DON'T WANT GRS, only LRS. I suppose Terraform can do it. Not normal since 2 years and no solution .... :-(
Please help !
@CedSadowski : As I mentioned earlier, SKU doesn't define LRS or GRS. You have to create a vault first and then update. Can you please file an issue/request with the terraform repo? I suppose they can help.
Hi,
To bypass this problem, I have defined my RSV and declare a script in AZ CLI to change immediatly the RSV SKU.
resource "azurerm_recovery_services_vault" "vault" {
name = "ced-recovery-vault"
location = azurerm_resource_group.main.location
resource_group_name = azurerm_resource_group.main.name
sku = "Standard"
soft_delete_enabled = true
provisioner "local-exec" {
command = "az backup vault backup-properties set --backup-storage-redundancy LocallyRedundant --name ${azurerm_recovery_services_vault.vault.name} --resource-group ${azurerm_recovery_services_vault.vault.resource_group_name}"
}
}
Any progress on this? I don't see an equivalent Azure backup policy for SQL databases as well.
I have been trying to do it via PowerShell modules, but that wouldn't work.
resource "azurerm_recovery_services_vault" "RSV"{
name = "RSV"
location = "eastus"
resource_group_name = "RGTEST"
sku = "Standard"
provisioner "local-exec" {
command = "Get-AzRecoveryServicesVault -Name ${azurerm_recovery_services_vault.RSV.name} | Set-AzRecoveryServicesBackupProperty -BackupStorageRedundancy LocallyRedundant"
interpreter = ["powershell", "-Command"]
}
}
For people looking at this, this is how we deploy the vault in bicep. Should be easy enough to build it into json.
param Location string
param Tags object
param VaultName string
@allowed([
'GeoRedundant'
'LocallyRedundant'
'ReadAccessGeoZoneRedundant'
'ZoneRedundant'
])
param BackupType string = 'LocallyRedundant'
resource RecoveryServicesVault 'Microsoft.RecoveryServices/vaults@2021-03-01' = {
name: VaultName
location: Location
tags: Tags
sku: {
name: 'RS0'
tier: 'Standard'
}
properties: {}
}
resource VaultConfig 'Microsoft.RecoveryServices/vaults/backupstorageconfig@2021-04-01' = {
name: '${RecoveryServicesVault.name}/VaultStorageConfig'
properties: {
crossRegionRestoreFlag: false
storageModelType: BackupType
}
dependsOn: [
RecoveryServicesVault
]
}
For those using Terraform, we had to use an ARM deployment right after creating the RSV to reconfigure it to use LRS (we did it in a Terraform module).
resource "azurerm_template_deployment" "rsv_lrs" {
name = join("", [azurerm_recovery_services_vault.rsv.name, "-lrs-config"])
resource_group_name = azurerm_recovery_services_vault.rsv.resource_group_name
template_body = file("${path.module}/storage_type.json")
deployment_mode = "Incremental"
parameters = {
"vaultName" = azurerm_recovery_services_vault.rsv.name
"vaultLocation" = azurerm_recovery_services_vault.rsv.location
}
}
{
"$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"vaultName": {
"type": "string",
"metadata": {
"description": "Name of the RSV"
}
},
"vaultLocation": {
"type": "string",
"metadata": {
"description": "Region that the RSV is in"
}
}
},
"variables": {},
"resources": [
{
"name": "[concat(parameters('vaultName'), '/vaultstorageconfig')]",
"type": "Microsoft.RecoveryServices/vaults/backupstorageconfig",
"apiVersion": "2016-12-01",
"location": "[parameters('vaultLocation')]",
"properties": {
"storageModelType": "LocallyRedundant",
"storageType": "LocallyRedundant",
"storageTypeState": "Unlocked"
}
}
]
}
For Terraform, LRS is now being supported with storage_mode_type which was introduced in v2.91.0 by https://github.com/hashicorp/terraform-provider-azurerm/pull/14659.
But I think there is still one question remaining, according to API Definition since sku
property allows RS0
and Standard
. However there is no official document explaining what this property is and how the value affects the recovery vault. @pvrk if this property is actually controlling something, I think it would be better to have a document for it, otherwise user won't be able to know how to use this property excepting trying and guessing it. If it's no longer used any more, maybe we can remove it in the new api version and put a deprecation notice in the document and in the issue.
Another thing I noticed is that sku
can be updated with a PUT
but not with PATCH
. Is this property supposed to change after a vault is created? Below is what I've tested with the REST API:
// Create backup vault
PUT https://management.azure.com/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/yicma-rg/providers/Microsoft.RecoveryServices/vaults/yicma-vault?api-version=2022-02-01
{
"location": "eastus",
"properties": {
},
"sku": {
"name": "Standard"
}
}
--------------------------------------------------------------------------------------
//Update sku with PATCH (Throws error)
PATCH https://management.azure.com/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/yicma-rg/providers/Microsoft.RecoveryServices/vaults/yicma-vault?api-version=2022-02-01
{
"sku": {
"name": "RS0",
"tier": "Standard"
}
}
Error is thrown:
{
"error": {
"code": "BadRequest",
"message": "PATCH is not allowed for the following attributesPassed sku: {\"name\":\"RS0\",\"tier\":\"Standard\",\"size\":null,\"family\":null,\"capacity\":null}, Existing sku: {\"name\":\"Standard\",\"tier\":null,\"size\":null,\"family\":null,\"capacity\":null}\n"
}
}
--------------------------------------------------------------------------------------
//Update sku with PUT (Works fine)
PUT https://management.azure.com/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/yicma-rg/providers/Microsoft.RecoveryServices/vaults/yicma-vault?api-version=2022-02-01
{
"location": "eastus",
"properties": {
},
"sku": {
"name": "RS0",
"tier": "Standard"
}
}
According to the spec https://github.com/Azure/azure-rest-api-specs/blob/master/specification/recoveryservices/resource-manager/Microsoft.RecoveryServices/stable/2016-06-01/vaults.json, it should be possible to set "sku" to RS0, however when trying to set that I get:
Another problem is that it isn't documented what the RS0 value actually does. I assume that it sets the storage redundancy type to LRS instead of GRS, but this is nowhere documented. If I change the redundancy portal in the portal, the generated ARM template changes:
from:
to:
See also related issue: https://github.com/terraform-providers/terraform-provider-azurerm/issues/2274