Backup for Azure IaaS Workloads
Updated: Aug 23
As organizations transition infrastructure that is on-premises to public cloud, backup often is lost in the shuffle. A great example of this is when companies move their Exchange servers to O365. Typically, Exchange servers are kept in Database Availability Groups (DAGs) when on-premises and the data protection team still backs them up daily. DAGs are great for high availability. If one site or server goes down, the end users are none the wiser as the database fails over to the secondary node. Furthermore, the same holds true with Oracle Real Application Clusters (RAC) or SQL Always on Availability Groups (AAG). These applications are replicated and protected from hardware failures, so they can quickly failover to the secondary node, but in all these cases the data is backed up as well. Although database replication is great for high availability, it does not protect against corruption, ransomware attacks, dubious or malicious employees. That is why backup is key whether managing the infrastructure or not.
Microsoft's Shared Responsibility Model
Whether creating net-new workloads or moving on-premises workloads to Azure, it is crucial to protect that data. As you can see in the image below (which is a diagram from Microsoft), end-users are always responsible for their data and who has access to it. Microsoft is responsible for the infrastructure by ensuring end-users are not effected by outages and disasters. They achieve this by replicating data across different zones within a data center and across multiple regions (if you pay up). This is no different than replicating data between primary and disaster recovery sites, when this data was on-premises. Companies still backed it up then and moving data to the cloud doesn't change this fundamental requirement.
Veeam Backup for Azure IaaS
Veeam offers the capability to protect Azure workloads natively. From Azure Marketplace, users can easily deploy a Veeam Backup instance for Azure, enabling them to create protection policies that define both snapshot and backup SLAs. In addition, a capability that sets Veeam a part from other solutions, is users have the ability to create a secondary copy on-premises or to another cloud provider. One of Veeam's core principles is 3 copies of data, on 2 different medias and 1 offsite. That principle doesn't change whether the production workload is in the cloud or on-premises. Veeam believes in this principle so much that it comes at no additional cost to move data to and from a cloud provider.
Veeam Backup for Azure in Depth
Veeam Backup for Azure both backup and snapshot IaaS workloads. Having the ability to define both in one policy is a great way to keep total cost of ownership down as snapshots can be more expensive than backups. Similar to on-premises, SAN snapshots typically sit on SSD or fast performing spinning disk which can be much more expensive than a backup on slow spinning disk.
When creating a policy, users define what resources to protect. The resources can be organized by subscription, resource groups, tags or VMs. If organized by subscription, resource group or tag, instances will atomically be removed or added to the policy with no manual intervention.
Once the resources have been selected, users define snapshot SLAs. Typically, we see organizations snapshot an important workload (whether it's on-premises or in the cloud) every few hours and retain that snapshot for a few days. This gives them a quick recovery point off of a SSD volume vs a disk based repository.
We can see in Azure that Veeam is taking snapshots.
It can be expensive to store snapshots for the entirety of an organization's retention policy though, so we typically see backups taken daily to a cheaper destination to fulfill the retention length. In the case of Azure, backups are stored in Blob storage for the length specified. During backup and restore worker nodes (proxies) are spun up to move the data. Once the backup or restore is complete the worker nodes are terminated.
Based on VM size, amount of resources being protected, and number of snapshots and backups retained, Veeam is able to provide a cost estimation for the storage and compute required in Azure. In addition, this can be a great way to help find a balance between the right amount of snapshots and backups to retain. For example, a 125 GB Windows VM with a 30 day backup retention only cost approximately $2.52 in Azure compute and storage resources, whereas a 125 GB Windows VM with a 30 day snapshot retention cost approximately $44.59. Finding the right balance can be a huge money saver. Below is a cost estimator based on the same 125 GB Windows VM with a combination of both snapshot and backup SLAs defined above.
From the Veeam Backup for Azure console, users have the option to do a VM, disk, or file level recovery for both Linux and Windows. No agent or extension is required for backup or restores.
Lastly, it is easy to create a secondary copy on-premises or to another cloud provider. The beauty of this is that all restore options from the Veeam backup server are still available. Users can instantly restore these Azure IaaS VMs to vSphere, perform a file recovery or even restore this as a running AWS EC2 instance if your organization has a multi-cloud strategy.
In the case of an instant VM recovery to vSphere, we see in the logs that Veeam does the conversion process since Azure disks are different from VMware disks. Veeam handles the conversion process behind the scenes automagically whether it is a restore to Azure/AWS or a restore back from Azure/AWS.
In summary, whether workloads are on-premises or in a cloud, organizations own their data. Cloud providers are responsible for the infrastructure, hardware failures and outages. The same way this strategy by itself doesn't protect organizations on-premises in a malware, ransomware, dubious or malicious employee attack hold true when that data is in the cloud as well.