In a previous post I wrote about customer inquiries involving data protection and recovery in the AWS public cloud, which typically spark similar questions about other public clouds, so to get in front of that I felt it best to cover data protection and recovery on the Microsoft Azure cloud.
While, officially, the Azure cloud is not a platform that we actively develop for, test, or support, I can confirm that due to the hardware abstraction of virtualization platforms, we have partners that are successfully protecting systems hosted and running on the Azure platform. In this blog, I’ll highlight how those partners are deploying, configuring, and restoring data with N-able™ Backup.
Since Backup is not natively aware of Azure and cannot interact with Azure directly, the backup manager must be installed locally within the guest operating system. In this type of deployment, the backup manager is not aware of the host hypervisor and behaves just as it would if it were running on a physical system. Installing the backup client can be done manually within the guest operating system or it can be scripted and automated as discussed in this blog post. When provisioning an Azure instance that will run a local backup manager client, you should avoid single core instance configurations and ensure that the backup manager has access to at least 500Mb of available free memory.
Recurring data protection for Azure hosted systems will function normally with access to the same backup features, plans, policies, profiles, and settings that are available to physical systems. However, I should clarify Backup does not store your encrypted backup data within the Azure cloud, which means all backup data is sent offsite to a regional N-able data center and Microsoft may charge for data egress from their cloud. To help reduce the data transfer in and out, I would suggest that partners layer their data protection by using a combination of Azure virtual machine snapshots for local protection and rapid recovery, and Backup for offsite protection and long-term archival.
All traditional file, folder, application, and volume level restore options are also available from within the backup manager and can quickly be used to correct a user error, accidental deletion, corruption, or even ransomware. However, advanced recovery tools like bare metal recovery, virtual disaster recovery, and the recovery console are not able to restore directly to Azure native installations. Situations requiring full recovery of the Azure native VM instance may require the combined efforts of deploying a new VM image or reverting to the most recent full VM snapshot, and then using the backup manager to selectively restore data and applications to the desired point in time.
While a direct virtual disaster recovery to Azure is not possible, the recovery console can be installed and run inside an Azure nested Hyper-V environment, allowing virtual disaster recovery, both on-demand and via continuous restore, to an offline VM. When configuring a nested Hyper-V environment, please choose an Azure VM with sufficient resources for your recovery needs. You can check regional availability of Dv3 or Ev3 series virtual machines here. In addition, Microsoft provides steps to migrate Hyper-V VMs to Azure, which could be used to later move those nested VMs into an Azure native configuration.
Eric Harless is the head backup nerd at N-able. Eric has worked with N-able Backup since 2013 and has 25+ years of data protection industry experience in sales, support, marketing, systems engineering, and product management. You can follow Eric on Twitter at @backup_nerd