A few tips and best practices for Microsoft Azure Backup

First published on TECHNET on Apr 12, 2016

~ Rupanter Chhabra | Support Engineer | Microsoft

Hi everyone, Rupanter Chhabra here again. In my last post I talked about Azure Backup portal and explained all of the options that we have there, and today I want to talk about some of the issues you may see in setting up Microsoft Azure Backup (MAB) as well as share a few best practices.

Getting Started

For Microsoft Azure Backup we need two things: Vault credentials and the Azure Recovery Services agent. You can find both of these under the Quick Start tab or in the right-hand side of Dashboard of the Backup Vault.

Vault Credentials

Note that Vault credentials are valid only for 2 days and you must install them again if you want to re-register the server.

The Microsoft Azure Recovery Services Agent

You can always find the LATEST agent for Microsoft Azure Backup here. You can install Microsoft Azure Backup on Windows Server or a client using the option selected above. Once downloaded you can proceed with the installation.

A few things to note during installation:

A quick installation guide for Microsoft Azure Backup can be found here: https://azure.microsoft.com/en-us/documentation/articles/backup-azure-backup-windows-server/ . Installation is fairly simple and well explained already, so I am just going to highlight a few things that we generally miss or are confused about that end up causing issues with backups. So let's begin!

Installation Settings

Here we have the Installation folder where we want MAB to be installed, but what we need to look for here is the Cache Location . Cache Location is something that is important as it stores the VHDs that are created after the snapshot is taken via VSS (Volume Shadow Copy). You can find the VHD's here if you have set the location of the scratch folder to the default:

C:\Program Files\Microsoft Azure Recovery Services Agent\Scratch\VHDs

The MAB agent takes a snapshot via VSS and then it creates a VHD in the scratch folder. Once the VHD is created during the initial replication (the first time the backup runs) then this VHD acts as the latest state for sequential backups that take place following the initial replication. This VHD is compared with the disks that we are trying to backup, and whatever changes are made in the disk are noted and compiled in a small new VHD. This VHD is then mounted and the data is sent to Azure. Once this is done the small new VHD is merged with the old one so that we have the latest state again for comparison the next day.

Now that we have an understanding of how the backup happens, let’s take a look at the 5%-10% of free space required. The creation of the VHD is a constant process of expansion and contraction as the data sent to Azure is compressed, so we recommend keeping the scratch folder in a location where you have at least that much free space. If you don't have the necessary free space then you can face multiple issues: The backups might fail completely, or the backup for one drive may work and the other might fail.

If you find that you need to change the scratch location after the backups have been started then you can do so by pointing the registry keys below to the new location where you want the scratch folder to be. Please note that you should stop the Microsoft Azure Recovery Service Agent service before making this change.

Change Registry keys:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Azure Backup\Config]

ScratchLocation

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Azure Backup\Config\CloudBackupProvider]

ScratchLocation

Registration

The rest of the installation is pretty simple and self-explanatory but I would like to note a few things about registration. When you register your server, you’ll see a tab where you are asked to enter a passphrase:

Please be aware that that the passphrase is the second level of encryption that we have; the first being the encryption of data that we do while sending the data to Azure. This passphrase is something that is very important when it comes to r ecovery of data from another server . Also note that if you recover data from another server, both servers should be in the same backup vault.

If you recover data from the same server using the This server option then the passphrase is not mandatory, however when you want to recover the data from another server the passphrase is necessary and without it you won't be able to recover the data.

If you lose the passphrase and want to recover the data from another server, but you don't have access to the main server, then as designed we will not be able recover the data. However, if you have access to the server and don't have the passphrase then there are a few options that can help us:

1. We can opt for Change properties using the console for MAB:

There you will see the Encryption tab and under that will be Change Passphrase :

You just need to click on the check box and you should be able to change the passphrase. Once that’s been done and the changes have been replicated to Azure, you can recover the data from this server using another server.

2. We can re-register the server (recommended):

For this option we have to go to the backup vault under Registered Items . We need to select the server under the type of Windows Server and in the bottom we will see a button for Allow Re-Registration :

Once we have allowed re-registration using this option then we can safely register the server again using the MAB console and enter a new passphrase there.

The Console

The first thing that you notice if your backups are failing is the Jobs section and the Alerts section which contain all the alerts that we need to check (e.g. update the agent).

If you click on any of the successful jobs you will usually see something like this:

For a failed job you will see two tabs: Items and Errors . U sually you don't notice the Errors tab but it can help you understand the exact nature of the issue with your backup.

Data

Many times we wonder "How much data have I sent to Azure from this server?" or "How can I check it?" Well the answer is right in front of our eyes:

You can also check how much total data has been consumed in the backup vault in the Dashboard of the backup vault.

Scheduling

There are a few things to note under the Schedule Backup option that may come in handy as well.

When making a schedule and planning to do multiple backups in one day, you must make sure that you allow some buffer time for the first job to complete. If the second job gets triggered before the first one completes then the second job will fail and give us an error. So again, in order to prevent that always give yourself some buffer time for job completion.

Another thing to note under scheduling is the data limit for o ne backup operation. This limit depends on which server you are on because if you are on Windows Server 2008 R2 then the limit is different from what it is on Windows Server 2012 and above. You can always check this on the Confirmation tab in the backup schedule just when you are about to finish scheduling.

Versions

Another question that often comes to mind is “What version of Microsoft Azure Backup Agent am I using?" The easiest and the best way to find out is to click on About Microsoft Azure Recovery Services Agent on the console of MAB:

In summary, there are a lot of things that the console tells us, we just need to figure out the location where that information is kept. I've tried my best to explain as much as I can and to keep it as simple as possible, so hopefully it will help you with a few issues if not all of them. Most of the issues we see are caused by the tiniest of the things that we fail to notice!

Rupanter Chhabra , Support Engineer
Microsoft Enterprise Cloud Group