terraform-provider-azurerm icon indicating copy to clipboard operation
terraform-provider-azurerm copied to clipboard

Point-in-time restore/Soft Delete for Blobs is not enabled if Operational Backup has previously been enabled

Open kxs-zdesai opened this issue 4 years ago • 1 comments

Community Note

  • Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
  • Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
  • If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform (and AzureRM Provider) Version

Found on TF 0.13.8, reproduced on TF 1.0.8

Found on AzureRM provider version 2.76.0, reproduced in 2.80.0

Affected Resource(s)

  • azurerm_data_protection_backup_instance_blob_storage
  • azurerm_storage_account

Terraform Configuration Files

Example: https://gist.github.com/kxs-zdesai/a87d0b553d4c34c7f9fefdaa34ac5a08

Debug Output

Panic Output

Expected Behaviour

When operationalBackup is enabled, "point-in-time restore" and "soft delete for blobs" is also enabled. Additionally, if the backup policy is replaced, point-in-time and soft delete should be updated to reflect the new retention policy.

Actual Behaviour

If operationalBackup has been previously enabled, Terraform will not set "point-in-time restore" or "soft-delete for blobs" on the storage account.

This occurs if Operational Backup was enabled by Terraform or manually. Manually enabling "point-in-time restore" or "soft-delete" does not trigger this behaviour.

Another way to observe the same/similar behaviour is to apply one backup policy and change to another - in this scenario, the retention days should align to the policy, but this does not occur and the values from the initial policy remain.

Failing case

  1. terraform apply the example code with backup_enabled=false
  2. Manually enable operationalBackup on the Azure storage account using the backupVault and policy configured by Terraform.
  3. Disable operationalBackup and uncheck/untick the boxes for Point-In-Time restore and Soft Backup.
  4. terraform apply with backup_enabled=true - observe that Point-in-time and soft backup are not enabled

Working case

  1. terraform apply the example code with backup_enabled=false
  2. terraform apply with backup_enabled=true - observe point-in-time and soft backup are appropriately enabled

Important Factoids

While manually enabling and disabling and then automating feels like a really fringe case, I think the bigger impact here is increasing from a 7 day to a 360 day retention policy won't update the pont-in-time restore values - that seems like it could be a more common use-case.

References

  • I have a hunch this may be related to https://github.com/hashicorp/terraform-provider-azurerm/issues/13665

kxs-zdesai avatar Oct 12 '21 16:10 kxs-zdesai

I've been able to recreate this same behaviour by performing this manually via the Azure Portal so may not be related to the Terraform provider. In the portal if you try to set up operational backup from the Backup Vault interface after having done it once it will fail, you can then only get it to work through the Storage Accounts interface where I assume there is some UI stuff that's actually making it work. Long story short this might be an Azure platform problem.

aaroncommify avatar Aug 08 '22 09:08 aaroncommify

Thanks for opening this issue. This was a problem in the 2.x version of the provider which is no longer actively maintained. If this is still an issue, and the same behavior occurs when performing this manually via the Azure Portal as @aaroncommify suggested above, I suggest you open a ticket with Azure Support to help resolve it. Thank you again!

rcskosir avatar Mar 15 '24 17:03 rcskosir

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

github-actions[bot] avatar Apr 18 '24 02:04 github-actions[bot]