Whenever using Veeam Backup for Azure, there are two popular options for creating multiple copies of the backup data. First is a backup copy job from an external repository. The second option is to rely on the native storage redundancy provided by Azure, such as geo-redundant storage (GRS) or read-access geo-redundant storage (RA-GRS). The purpose of this article is to explore this second option by leveraging RA-GRS to achieve backup redundancy across two Azure regions.
As a quick reminder, with RA-GRS and GRS, the data is stored in two separate locations, with one being the primary location and the other being a secondary location. The secondary location is located in a different geographic region than the primary location, ensuring that data is safe even in the event of a regional outage or natural disaster.
It’s worth mentioning that while GRS helps ensure that backup data is safe even in the event of a regional outage or natural disaster there are some potential disadvantages with it. For starters, I don’t consider backups stored in GRS as a true ‘independent’ second copy of your backup because GRS replicates blobs with corrupted data inside them. This means any corrupted backups would also be replicated in the second region.
Secondly, we must consider that GRS uses asynchronous replication to the target region. An unplanned failover could result in blobs not being replicated at the target which would likely lead to restore or backup failures. While the possibility of this happening is quite slim, it can’t be ruled out.
For more detail on the different types of Azure storage check out my previous writeup here
For testing, An RA-GRS storage account was provisioned in Australia East from which Azure automatically configured the secondary region to Australia Southeast. This paired secondary region is determined based on the primary region and can’t be changed. Access to the storage account is via public endpoints.
Note: A GRS storage account is preferred over RA-GRS for production environments. A read-only copy might be useful for DR testing but this was not verified during my testing.
Veeam Backup for Azure was then configured with a new backup repository on the newly provisioned RA-GRS storage account. A backup policy was created to protect a single Azure VM. The backup ran numerous times without issue with test restores being performed to validate that everything was in order.
At this point, the failover of the storage account to the secondary region was initiated via the Azure portal.
To estimate the extent of likely data loss before initiating a failover, check the Last Sync Time property. When initiating a failover for the storage account, the DNS records for the secondary endpoint are updated so that the secondary endpoint becomes the primary endpoint.
Reviewing the Veeam Backup for Azure console during the failover did not immediately indicate an Azure storage account failover was being performed in the background. However, any backup policies scheduled to run would result in an error until the failover was finished. Attempting to edit the backup repository also resulted in the below error.
After the storage account failover is completed, the Veeam repository properties can be modified without any errors experienced and scheduled backup policies also resume without any faults.
The time it takes to failover after initiation can vary though typically less than one hour. In my test, the failover took less than 15 minutes to complete.
After the failover finished, several restore tests were performed to validate that recovery is unaffected by the change.
After the failover, the storage account type is automatically converted to locally redundant storage (LRS) in the new primary region. It’s easy to re-enable geo-redundant storage (GRS) or read-access geo-redundant storage (RA-GRS) for the account but note that converting from LRS to GRS or RA-GRS does incur an additional cost. The cost is due to the network egress charges to re-replicate the data to the new secondary region.
After re-enabling GRS for the storage account, Microsoft will begin to replicate the data in the storage account to the new secondary region. Replication time depends on many factors, for my small test repository it took less than 1 hour.
Fortunately, the replication did not impact any scheduled backup policies or restores. So while the replication may take a long time to complete, it can run without disrupting Veeam.
An additional note, the Veeam Backup for Azure still showed the Azure region as Australia East even though the Storage Account had successfully failed over to Australia SouthEast.
In summary, by configuring an Azure Storage account with RA-GRS or GRS, you can ensure that your Veeam backups are not only protected in the primary location but also in a secondary location that’s located in a different geographic region.
This means that even if a disaster or outage occurs in the primary location, your data is still protected and can be quickly and easily recovered from the secondary location.