Cloud Backup support read access geo-redundant replication

[MarcelB]

Veeam Cloud Backup is able to use Azure Storage as a backup target. Azure Storage has a feature in preview which allows read access to replicated storage.

Geo-replicated data in Azure is only accessible for customers when Microsoft decides a failover of storage is required. While Microsoft tries to fix the storage issue, customers cannot access the data.
Read access geo redundant storage solves this. Azure customers are able to have read-access to the replicated data.
This read access geo-redudant storage uses a different endpoint to access blob storage: https://<storageaccountname>-secondary.blob.core.windows.net/
The storage account + primary key required for access is the same for both primary and replicated storage.

Will Veeam Cloud Backup support accessing the replicated data at the secondary site?

[foggy]

Marcel, as far as I understand, Veeam B&R Cloud Edition will be able to seamlessly switch to the secondary endpoint in case of geo failover (once DNS entries are updated). After a failover, the secondary location will become the primary location for the storage account, and Veeam B&R Cloud Edition will be automatically pointed to it.

However, if we are talking about using Read-Access capability to perform restore from the secondary location (while the primary location is up and running), then, I suppose, you would need to create a separate account for 'myaccount-secondary' endpoint within Veeam B&R Cloud Edition for that. Make sure you perform repository synchronization and use Cloud Edition Advanced mode in this case. Current GRS replication implementation allows situations where each of the files itself is consistent, while different files can have different versions (e.g. the latest version of one file is already replicated, while the latest version of another is not). This can result in not all of the files having the latest version when restoring multiple files. Cloud Edition Advanced mode stores each file version in a separate location (instead of overwriting it) and prevents such situations ensuring all the files have consistent versions within each restore operation.

Anyway, this is just a theory, if you have an ability to check this and post the results here, it would be much appreciated. Thanks!