Azure storage account container could not be added on version 12.2 & 12.3.

[jerryfan]

We have blob container (that has old data) can be added on version 12.0 without any issues. While after we deploy new version 12.3 that the container could not be added on new version. After troubleshooting with VEEAM support, I was told that when soft delete or immutability was enabled on existing containers, it can't be connected to Veeam server version 12.x. The workaround is to create a new container and add it to Veeam. The data on affected container should be copied manually to new container and can be restored when needed. Otherwise we need to keep 12.0 in our environment.

From my understanding, it should be relative to latest VEEAM version issue as I do not think end user need to manually move the data across the different storage account.

Have you meet the same issue?

[KirillChuxlancev]

Indeed, the scenario of enabling immutability on an existing Azure blob storage container is not supported (https://www.veeam.com/kb4416) as well as Azure blob soft delete feature (https://helpcenter.veeam.com/docs/backu ... ml?ver=120). However, these are the settings of the cloud side and I don't see how the upgrade of the Veeam server affects it. Could you, please, share the support case number? We would check the context of the issue on out end.

[Lei.Wei]

Hello Kirill.
I am the SE working with Jerry. The case number is 07662251.

[KirillChuxlancev]

Hello, thank you for sharing the case number.

It appears that the issue is related to the validation of the Default Immutability Policies presence. The check was introduced in v12.2 to prevent misconfigurations that could lead to backup corruption. During this validation process, a small meta-object is temporarily created in the target repository and removed at the last step of the algorithm. The deletion failed due to a snapshot being present for the meta-object, which triggered a 409 Conflict error

I recommend continuing to work with support to manually removing both the meta-object and it's snapshot (located in the storage container under the path CheckDefaultImmutability/blob). Additionally, please ensure that soft delete is disabled and investigate the source of the snapshot creation (it could be triggered by Azure automation or third-party software.). After identified, the snapshot creation shall be turned off as well, as Veeam server has to exclusively manage the whole content of the object storage repository (https://helpcenter.veeam.com/docs/backu ... ml?ver=120).

That said, the limitations mentioned above are still relevant for the case and should be reviewed accordingly.

[jerryfan]

Hello KirillChuxlancev,

Thank you for your clarification and I can add the blob successfully after the blob file is deleted under CheckDefaultImmutability folder.
By the way, is there any chance we can improve this operation that there is no need to manually remove this folder by end user during next version of VEEAM?

[KirillChuxlancev]

Hello Jerryfan,

I'm glad the previous information was helpful!

Regarding the enhancement you're considering — the reason a removal operation failed is due to a snapshot being attached to the blob. Veeam doesn't interact with snapshots when working with Azure storage, so when it issues a delete request for the object, it doesn’t include any instructions to handle existing snapshots.

If the storage account is configured according to the recommended policies, Veeam will be able to remove the object automatically, without any need for manual intervention — assuming no snapshots are present.

[jerryfan]

Thank you KirillChuxlancev, well noted and understood. We will disable soft delete before we add the storage account to VBR server.