Review & Re-design our Veeam Backup Storage options

I totally agree that you don't need GRS repositories at this point as you already have a copy of the backup to Vault. The strategy look ok, create the new LRS repos and wait the GRS backups be deleted by the retention.

Regarding the regional outage, you would need to create a new VBAzure appliance in the region and then just add the repository using the other region. The backups would be imported and ready to restore. 

Another point, do you really need hourly snapshots? Just asking because this cost a lot of money if the VMs have big disks. 

Thanks ​@wesmrt that's very helpful. Just to clarify one point regarding the move away from GRS: in Azure Storage there appears to be an option to change the redundancy setting from GRS to LRS. Would there be any reason not to use this approach? If the redundancy can be changed successfully and remains a supported configuration for Veeam Backup for Microsoft Azure, we could potentially continue using the existing storage accounts, repositories and backup chains without needing to create new LRS-based storage accounts and repositories.

Alternatively, would Veeam still recommend creating new repositories and redirecting future backups there? If a new LRS repository approach is recommended, how would the existing data in the current GRS repositories be handled? We would obviously want to avoid paying for both the new LRS repositories and the existing GRS repositories for an extended period. Would we need to wait for the current retention periods to expire naturally (e.g. 31 daily restore points and monthly retention points) before retiring the GRS repositories, or would Veeam establish a new backup chain on the LRS repositories first and then allow the existing GRS backups to age out over time? I'm particularly interested in understanding the recommended migration path and how the existing GRS-based backup data is ultimately cleaned up and retired.

You could just change the from LRS to GRS, I dont believe this would be a problem because it's something on Azure side. When you change the copy of the data wont happing anymore to other region, but the data on the storage account wont change. 

However, I never seen a customer doing that. Usually the customers prefer to create a separated storage account, create a separated repository and changing the policies to this new repo. When you do this, a new backup chain will be created.

Regarding the old repository you just need to wait for the retention remove the restore points when they expire. The retention run everyday for all repositories, so you dont need to worry with the fact the policies are not using the old repository. Also, you could delete the repository on VBAzure and then delete the storage account from Azure if in some point yiu dont need the old restore points anymore. 

Thanks ​@wesmrt I am still struggling to see additional benefit of creating new storage accounts / repos for LRS when there is an option to change the redundancy in Azure from GRS to LRS and it is pretty smooth and wont have any impact on existing data and will keep the back chain in tact etc. 

I really believe it's totally fine to just change to LRS. It should be transparent to the VBAzure. If you find any error you can open a case with Veeam and we can check. 

Hi ​@gabbas 

I’ll try to give you a general answer, as I don’t know your RTOs and RPOs 
There are pros and cons to using GRS storage; for me, there are more cons when it comes to using Azure GRS storage as a backup repository.

GRS replication is asynchronous: a regional failover may occur before all data has been replicated → no guaranteed zero RPO, possible restore/backup inconsistencies.
GRS replicates "as-is", including potentially corrupted backups: it is not an independent copy. A separate immutable Backup Copy (e.g., Data Vault) provides stronger protection against corruption/ransomware.
GRS costs more (storage + geo-replication data transfer), while Data Vault already provides a dedicated offsite immutable copy.
You can create new LRS repositories for new backups and keep existing GRS repositories for restore purposes only, until data ages out.
Restores from existing GRS repositories will continue to work normally as long as the repositories and underlying storage accounts remain registered and available.

With monthly/yearly GFS retention, data will remain in the GRS repositories for months/years: cost savings will be gradual, not immediate.
Do not use Azure Lifecycle Management policies to remove data from Veeam repositories: retention and deletion should be managed exclusively by Veeam to avoid backup/restore failures.
GRS provides infrastructure-level geo-redundancy, but recovery is not automatic, requires operational intervention, does not guarantee zero data loss (asynchronous replication), and offers limited additional value if an immutable offsite copy (e.g., Data Vault) is already in place.

I would say that the proposed architecture is in line with best practice. Using LRS on primary repositories when a second, truly independent layer of protection already exists (a Backup Copy Job to an immutable off-site repository, e.g. Data Vault) is consistent with the principle of not paying twice for the same guarantee of resilience. The right question is not “GRS or LRS?” but “What RTO/RPO am I willing to accept in the event of a regional disaster, and does the Backup Copy Job to the Data Vault already cover this?”. If the answer is yes, GRS becomes a redundant cost.

Hourly snapshots: these do not provide protection against a regional outage because they remain in the same region as the VM. In the event of disaster recovery, restoration will still be carried out from backups (Veeam Data Vault or GRS/LRS repositories), not from snapshots. Consequently, their value for geographical resilience is limited, and their removal may be considered if they are not required to meet very stringent local RTO/RPO requirements.

Do not remove GRS wholesale: before removing it everywhere, consider retaining it selectively on repositories with annual/critical GFS retention and low volumes, where the incremental cost is low but the ‘free’ extra copy may be valuable as an additional safety net. Move mainly daily/monthly volumes to LRS, where the savings are most significant.
 check : 
Veeam Backup Repository / Microsoft Azure Object Storage | rhyshammond.com
Failing over GRS Azure Storage with Veeam | rhyshammond.com

best regards mate