June 14, 2017
How to Back Up VMs to Azure – Part 1
One of the hard and fast requirements of today’s modern backup solutions is the ability to be able to push data to the cloud as an offsite backup option. Offsite backups are essential as they protect organizations from potential data loss when losing an entire site. With the 3-2-1 backup rule standard of 3 copies of your data on 2 different types of medium and 1 copy of the backups offsite, the best practice to ensure resiliency is to have at least that one copy of our backup production data stored offsite. NAKIVO Backup & Replication continues to show that cloud DNA is a primary component of the product as it allows customers the ability to move backup data to not only Amazon’s AWS cloud but also to Microsoft Azure. In the first post, we will take a look at using VM provisioned in Azure that is running the NAKIVO Transporter service and remote repository as a target for offsite backups.
Methods of Connecting NAKIVO Backup & Replication to Azure
There are a couple of ways we can go about configuring backups from NAKIVO Backup & Replication to the Azure Cloud. The first method we will look closely at in this first post is accomplished by provisioning a VM with a supported operating system in Azure, install the Transporter role, and then provision a repository from our NAKIVO Director server. Let’s take a look at the steps involved with this method.
First, we provision the new virtual machine – name, disk type, user name, password, Resource group, etc. Here I am provisioning a Windows Server 2012 VM.
The next screen is simply where we size the VM. ***Note***, for the purposes of this tutorial, I am using a simple “temporary storage” enabled VM, meaning the data is not persistent. We would definitely not use this for production. We would create a persistent disk to store our backup data.
Next, we setup the network settings for the virtual machine. We will talk about this later, but we will need to make some adjustments to the network settings to allow the NAKIVO specific traffic through to our virtual machine.
Finally, we see the summary screen of completing our configuration. Review the settings here and make any adjustments that need to be made.
Now, we run the NAKIVO Backup & Replication Windows installation on our virtual machine. On the installation type we choose the Transporter only installation. If we chose Full solution, we would also be installing the Director component that would expect to have its own connection to our VMware or Hyper-V inventory. However, we want to use our existing Director server and inventory connection to our production environment and only use our cloud resource as a transporter and repository.
If we click the Options button on the installation screen, we will see additional details of our installation. As mentioned above, there are network connectivity considerations to be made in our configuration for cloud connectivity. As shown, the default Transporter port is 9446. We can either leave this as default or if we have another port we need to use for our business needs we can set that here as well. We need to make sure that the firewalls in between will allow the traffic through to this port. This includes our Azure network security group configuration. By default, it will create a simple “RDP allow to all” rule which is port 3389.
After we click Install and the installation completes, we will see the “next steps” actions that need to be completed on our Director server. Basically we need to add the new cloud transporter to our NAKIVO environment and then create a new repository in the cloud utilizing the cloud transporter.
Below, I have logged into the NAKIVO Backup & Replication Director server appliance and navigated to the Transporter configuration. We choose to Add Existing Transporter and choose the Local / Offsite option. Enter the IP address of the Azure Transporter virtual machine that we have provisioned above. Make sure to match the Transporter port to the port you specified in the Transporter installation if different than the default. Finally, name the Transporter. For easy identification, I am simply calling it Azure Transporter.
The addition of the Azure Transporter should complete successfully. You will be able to expand it and see the configured properties.
Now, we can create a new Repository in the Azure cloud. Click on the Add Backup Repository >> Create new backup repository link. Here we choose to use our Assigned transporter “Azure Transporter”. Also, notice the Path to the local folder is set to “D:\”. NAKIVO Backup & Replication will automatically create a NAKIVOBackup directory under the directory we specify.
Below, after we specified the D:\ drive for our repository, we see the NAKIVOBackup directory created along with the default files and folders for the repository.
At this point, we have a functioning Transporter and Repository located in our Azure cloud. We can now select it as a destination for our backup and backup copy jobs as we would any other destination repository.
Advantages and Disadvantages
There are a few advantages and disadvantages to note when comparing this approach to the SMB copy method we will describe in the next post.
- Utilizes NAKIVO technologies for speed and security
- Network acceleration and transporter to transporter encryption
- Provides faster transfers
- More robust from a design perspective
- Doesn’t require SMB ports over a WAN connection
- Requires more configuration
- Full VM has to be provisioned – required in Azure including all the OS level and security configuration needed to meet business needs
- Costlier from a cloud perspective (uses compute along with storage/network)
In this post, we have taken a close look at the full VM approach to backing up to Microsoft’s Azure cloud service with NAKIVO Backup & Replication. This provides a powerful, robust solution to achieve offsite backups and allows the use of NAKIVO’s network performance and security enhancing technologies – Network Acceleration and Encryption between transporters. Also, there is less complexity from a network connectivity standpoint since we don’t have to open all the ports required for SMB connectivity. However, there are use cases for the next method we will discuss – using an on-premise transporter and creating our offsite backups in Azure using an SMB file share.