How to Backup VMs to Azure - Part 2
Brandon Lee, posted on June 19, 2017
In the first post of this series on how to backup VMs to Microsoft Azure, we looked at using an Azure VM running the transporter service and then provisioning a remote repository. The second method to achieve offsite backups to Microsoft Azure uses the SMB protocol to copy our NAKIVO backups to an Azure file share. The file share can be provisioned without utilizing a virtual machine in Azure. We simply provision a file share under a storage account.
Connecting NAKIVO Backup & Replication to an Azure File Share
As mentioned above, a second option to connect NAKIVO Backup & Replication to Azure is to create an Azure file share and use the SMB protocol to copy backups to the cloud share. The difference in how we architect the file share method is that we will have an on-premise Windows transporter that we will use as the conduit to connect to the cloud file share. The reason we have to use a Windows transporter is there are technical limitations of Linux or NAS based transporters using Azure file shares. Let’s take a look at how to setup this method of Azure cloud backups.
Provision an on-premise Windows Transporter
The first step is to provision a Transporter service on a Windows server to connect to the Azure file share.
Once again, we can take note of the transporter port so that we can make the appropriate firewall exceptions in all the firewalls in between so we have no issues with network communication. We can see this by selecting the Options link in the installation dialog box which will expand the viewable information including the port used, etc.
Creating an Azure File Share
Now that we have an on-premise Windows transporter, we can create the file share in Azure. To do that, navigate to Storage >> Storage account -blog, file, table, queue.
Now, we can create a new storage account so that we can then create a file share. Most of the options are self-explanatory. I am using an existing Resource group.
Once we create the new storage account, we then click on the storage account and navigate to Files which is where we provision the file share.
Click the “+ File Share” to add the file share.
Here I created a new file share called nakshare. The quota basically sets the storage limit on the file share so you can control the maximum amount of data that is copied to the share. Click OK to create the share.
The last bit of information we need to actually use the file share is the connection information (username, password). To find the information we can click the new file share that we have created and click the Connect button.
This will bring up a box containing an actual net use statement with the file share path as well as the user name and password exactly as you would enter it in a commandline with net use. As mentioned in the connection box, we need to make sure we have port 445 opened incoming as well to go along with our other firewall considerations.
A note here – You can also find your password information to connect by clicking on your storage account name >> Access keys and then you will see your access keys, a.k.a passwords, in the right-hand window under the Default keys designation.
We can also test our connection by simply creating a network drive mapping to the Azure file share, if we so desire to make doubly sure we have the correct connection information.
Now, we should be all set to configure NAKIVO Backup & Replication to use the new Azure file share as a new backup repository. First, we add the onsite Windows Transporter that we created.
Next, we create a new backup repository and use the same connection information we found above to be able to add the file share as a Remote CIFS share.
Once we add the connection information, we should see the new repository successfully added.
Advantages and Disadvantages
There are a few advantages and disadvantages to note when comparing this approach to a fully provisioned VM solution with the Transporter service running in Azure.
- Fewer moving parts in Azure – no requirement to provision a virtual machine
- Less costly from a cloud perspective (only utilizing storage/network only and not compute)
- Not able to take advantage of encryption between transporters
- NAKIVO network acceleration also is not available
- Slower than the full VM/transporter solution
- Requires SMB network access over the WAN
As shown in this and the previous post, NAKIVO Backup & Replication allows us to utilize Microsoft’s Azure cloud to store backup data. NAKIVO is a cloud diverse platform that allows us to use the cloud providers who are the industry leaders – Amazon AWS as well as Microsoft Azure. We can choose how we connect to Microsoft Azure by either running a virtual machine in the Azure cloud where we can install the Transporter role and allow NAKIVO Director to create the remote repository. Or, we can run a Windows Transporter on premise and then utilize an Azure File Share as a Remote CIFS share as a destination repository. As we have shown here, both methods are easily provisioned and allow us to provide site diversity for our backup data as well as have offsite backups to satisfy compliance and other business requirements. Offsite backups are essential in today’s enterprise environments and being able to utilize the cloud to store backups helps businesses meet this critical need.