My Experiment with Recovery Services Vault – Azure Backups

Today I created my own Recovery Services Vault with a client Azure Backup using the new Azure Portal. The well-written documentation “Back up a Windows Server or client to Azure using the Resource Manager deployment model” [link here] made this process relatively painless.  My first-timer confession is that because my Udemy course had transitioned from storage accounts to this topic, I had thought that I would be creating a backup of my Azure storage accounts. Since my course was already outdated in showing this process using the classic portal (which is very different), I relied on the Microsoft documentation online to complete the process using the new Portal.

So, I found out this service creates backups of files, folders, etc… from your local windows server or windows client (in my case, my personal laptop) on Azure’s cloud, not the other way around.

My Thoughts: I think this service would be OK for systems administrators backing up Windows Servers and Azure related data for work applications, but personally I would not prefer to utilize this for my home PC, my home backup needs, or even my business use. I will stick to my Drop Box because of the user interface experience and other issues.

Creating a Recovery Services Vault

Finding the Recovery Services Vault blade is hidden under the Main Menu -> More Services -> Storage category. I followed the motions from the Microsoft documentation to create my service and began to configure.

Installing a Recovery Services Agent

In the service blade when you configure the vault for backup, it asks you to download and install the Microsoft Azure Recovery Services (MARS) agent. You can go ahead and install it but you need to skip ahead to first download a Vault Credential file, then in the configuration process of the MARS agent identify where this vault file is stored.

Configuring the Microsoft Azure Recovery Services (MARS)

My MARS agent configuration user experience was an unpleasant trip down memory lane to the 1990’s style of Microsoft windows style programming. The “Select Items” dialog window had no speedy way of changing directories. It would had been nice to paste my directory location into a text box to navigate to the folder that I originally wanted to experiment with, but seemed like a mile of user clicks away to navigate to, so I ended up picking some place simple and close to the C: drive.

Next the MARS agent brings up a Scheduling and then Retention Policy configuration display. As a developer I have made “windows form style” applications look more stylish with controls, groups, and user experience layouts. From Microsoft I would expect a modern UI look and feel with some Azure color branding like blue… but this application was still functional.

Also, not to sound too whiny here, but I was a little concerned in not seeing proper identification of my Backup Items under the Scheduled Backup, job details, and other user interface areas. One could think that their entire C: drive is scheduled to be backed up or recovered (when you select the Recovery action item) and have a minor panic attack!

Backing up the Microsoft Azure Recovery Services (MARS)

To clarify, I had only chosen one folder directory and file for backup in my configuration. It was a 1 KB file of no significance other than I wanted to test out this backup process.

It is recommended you seed the vault with an initial Backup instead of waiting for the scheduler to do so for you, so I clicked on the Action “Backup Now”. The initial Backup process unexpectedly took about 5-10 minutes for 1 KB file. Not sure if the process time is proportional to data quantity, but if it is, you may wish to do this over your lunch break.

After this backup process had completed I noticed from the Job Details my 1 KB File had produced 1.24 MB of Data Transfer, which seems like a gargantuan amount of meta data or other junk (and it said it was compressed) along with my tiny data file.

 

Job Details and Status of Backups

I had let the MARS program perform an initial backup seed then its first scheduled backup before I checked out the details in both my client application and the new Azure portal.

Here was my client application Job Status

In the new Azure Portal, I noticed the scheduled backup job status did not change to complete until after ~5-10 minutes of refreshing the blade. Note: The client may say the backup job is complete but the portal may have a different status not in sync [potential bug?].

An Unexpected Side Effect?

After I had completed my backup in the MARS client on my laptop, I wanted to check the backup job status (see above) and other details in my new Azure Portal Recovery Services Vault. However, I was dismayed that my Internet went down.

I took a 10-minute break and came back to find the Internet still out and none of my websites working on the laptop. I then decided to test out my WIFI-only iPad mini, and it still retained connected to my Internet. The same with my other devices.

Very strange indeed. I turned off, then turned on my laptop WIFI connection, and fixed the Internet outage.

Summary

As mentioned in my introduction, this MARS client program may be good for backing up Azure applications or Windows Server applications but I would prefer not to utilize this for my every day file and folder backups. The client program also has some room for improvement in the user experience and interface design.