terraform-provider-azurerm: azurerm_backup_protected_file_share Unable to Create Due to Azure Internal Error

Can confirm 2.46.1 works fine

There is a possible stop-gap solution by using the Azure CLI - you can use it using the null_resource and then using the local-exec provisioner.

It’s not without problems:

• The destroy command will error, so you will have to manually delete the backup first in the Azure portal.
• You need to have az installed and logged in on whatever machine you are running
• It’s slow (although I think caused by Azure API)
• Using the local-exec provider is an anti-pattern, or at least a last resort

I would advise against using the command outside Terraform (which was my initial thought). This is because if you rerun this command, it will fail. Therefore, running it in Terraform and appending it to the state makes a lot of sense.

However, as soon as this issue is fixed, I would strongly recommend changing it back to the officially supported resource.

resource "azurerm_storage_account" "account" {
  location = azurerm_resource_group.rg.location
  resource_group_name = azurerm_resource_group.rg.name
  name = "example"
}

resource "azurerm_storage_share" "data" {
  name = "data-accunt"
  storage_account_name = azurerm_storage_account.account.name
  quota = 50
}

resource "null_resource" "enable-backup" {
  provisioner "local-exec" {
    command = <<EOT
az backup protection enable-for-azurefileshare \
  --resource-group "${azurerm_resource_group.rg.name}" \
  --vault-name "${azurerm_recovery_services_vault.vault.name}" \
  --azure-file-share "${azurerm_storage_share.data.name}" \
  --policy-name "${azurerm_backup_policy_file_share.policy.name}" \
  --storage-account "${azurerm_storage_account.account.name}"
EOT
  }
}

There may be other configurations that work, but this works for me. For the record, I’m doing this on a Data Lake Gen2 account, but this also seems to work on normal storage accounts although I’ve done much less extensive testing on that.

@rajakesar With the recent GA release of Azure File shares backup, a unique identifier has been introduced for each file share and hence for protecting any share, the recommendation is to pass the unique Id of file share in the PUT call rather than friendly name. To fix the issue, you can follow the below steps:

1.Do GET backupprotectableItems API call for the vault that you want to use for configuring protection for file share. 2. Filter the response of above GET call with the friendly name attribute as the “friendly name of your file share”. 3. After filtering , the response object will have details only for the file share that you are trying to protect. The name attribute of this response is the unique ID for your file share. 4. Do a PUT protecteditems call using this unique ID rather than friendly name. This should configure protection successfully for your share.

Here are few links for your reference:

https://docs.microsoft.com/en-us/azure/backup/backup-azure-file-share-rest-api#select-the-file-share-you-want-to-back-up

https://docs.microsoft.com/en-us/azure/backup/backup-azure-file-share-rest-api#enable-backup-for-the-file-share