Azure Backup: A Walkthrough

Welcome back folks. It’s been a while since I last posted as it’s been all go at my new job, learning LOADS, so that’s good 🙂

Recently I’ve been putting together some operational documentation on Azure Backup and decided to flesh things out a bit and blog on it…why not right?

As is becoming customary with my posts, this is likely to be a lengthy one as it’ll be covering a fair bit, in some detail.

This guide will mainly focus on using Azure Backup in an IaaS scenario but I’ll also be touching on the Azure Backup agent in part 2. I may end up writing a Site-Recovery piece at a later date, if so, I’ll link to it HERE

Here’s an overview of what’s covered in this post:

• Azure Backup Overview
• Deploying and Configuring a Recovery Services Vault
• Create a Backup Protection Policy
• Enable/Disable Protection for an Azure VM

As well as providing a step by step using the portal, the end of each section will have the PowerShell for completing the same tasks.

Azure Backup Overview

I thought about doing a write up of all the current features, deployment scenarios and reasons to use Azure Backup but that’s been pretty well covered by Microsoft and has the added benefit of being updated as the landscape changes. With that in mind, it makes much more sense to link it 🙂 …so HERE IT IS!

If you’d rather not go and read all that, here’s are gist of it:

• Automatic Storage Management – No charge for using on-premises storage with Azure Backup. Azure backup will automatically allocate and manage backup storage (in the cloud) and uses a pay-as-you-use model. In other words, you’re charged for the storage you use, e.g. if a VM has 100 GB of storage configured, but the backup of that VM is only 25 GB, you pay for 25 GB of backup storage.
• Unlimited Scaling – It’s cloud right, highly available and all that.
• Unlimited Data Transfer – No limits on inbound (a backup job)/outbound (a recovery job) data transfer. You’re also not charged for data transferred unless you make use of the Azure Import/Export service, more information on that HERE and HERE
• Multiple Storage Options – This refers to storage replication, of which there are two types available through Azure Backup. There are:
  • Locally Redundant Storage (LRS) – 3 copies of your backup data are stored within a storage scale unit in an Azure datacentre (all copies exist within the same region).
  • Geo-Redundant Storage (GRS) – This is the default and recommended option (See note below). With GRS your backup data is replicated to a second datacentre in a different region to your Recovery Services Vault. As expected, this option costs more but the upside is that your data will survive a regional outage.

NOTE:  As mentioned, GRS is the default storage option when you set up a Recovery Services Vault (RSV). This can be changed to LRS once the RSV has been deployed but make sure you do this before kicking off any backups as you’ll have to delete them again as existing backups will lock the option out.

• Data Encryption – When backing up using the Azure Backup Agent, your backups are encrypted in transit and at rest using an encryption passphrase.  This is stored locally and is never transmitted to Azure or stored up there.  This passphrase is required for a restore of the encrypted data.
• Application Consistent Backup – Using MSSQL as an example, VSS is used to quiesce the database, flush it’s memory cache and complete all of its writes before taking a snapshot. VSS will then tell MSSQL to get back to work. This also means in the event of a restore, no additional work is required to restore the database.
• Long Term Retention – You can store stuff longer than you’re likely to be alive :). Also a protected VM can have 9999 restore points.

Now let’s list a few of the limits associated with Azure Backup

• 25 Recovery Services Vaults, per supported region, per subscription.
• 200 Azure Virtual Machine registrations per vault
  • 50 Azure Backup Agent registrations per vault
  • 50 Azure Backup servers/DPM servers per vault
• Azure VMs can be backed up once a day
  • DPM twice a day
  • Windows Server/Client 3 times a day
• Maximum of 16 data disks attached to an Azure VM
• Maximum data disk size of 4 TB (See note below), otherwise it’s 1 TB, a little more on this later.

NOTE:  This requires a one off subscription upgrade, has potential cost implications and it a one way change (See screenshot below).

That should be enough information to get the ball rolling, so let’s get on with the fun stuff.

Deploying and Configuring a Recovery Services Vault

OK, so we’re working towards backing up an Azure IaaS VM, to do that the first thing we’ll need to deploy is a Recovery Services Vault (RSV).

• Log into your Azure subscription and click “Create a Resource”
• Type “Backup and Site Recovery” into the search bar

• Select “Backup and Site Recovery (OMS)” from the menu and click “Create”

• Enter a name for your RSV
• Create a new resource group or select and existing one
• Select a location for your RSV (See note below)
• Click “Create”

NOTE:  You want the location to be the as the VMs you’ll be backing up

The deployment should only take about 30 seconds or so, so keep an eye on the notifications area 🙂

• We can jump straight to our newly created RSV by clicking on “Go to resource”

Now as I mentioned earlier, the default storage replication setting for a vault is GRS, for this example we’re going to use LRS, mainly so I can show you how to change it.

NOTE:  Remember, this option will be greyed out if you have a protected server in the vault.

• Under “MANAGE”, click “Backup Infrastructure”, then “Backup Configuration”
• Select your preferred “Storage Replication Type” and click “Save”

Using PowerShell

# Log into Azure tenant and set subscription (Update "[0]" to target the required subscription if you have multiple)
Import-Module AzureRM
Login-AzureRMAccount
Set-AzureRmContext -SubscriptionId (Get-AzureRmSubscription)[0].SubscriptionId

# Register the required providers (not required if you've used Azure Backup under this subscription before)
Register-AzureRmResourceProvider -ProviderNamespace "Microsoft.RecoveryServices"
Register-AzureRmResourceProvider -ProviderNamespace "Microsoft.Backup"

# Create a resource group for our Recovery Vault (Updated the name as required)
$ResourceGroup = New-AzureRmResourceGroup -Name "DF-TestRSV-PowerShell-RG" -Location "CentralUS"

# Create Recovery Services Vault (Change name as required)
$RSVault = New-AzureRmRecoveryServicesVault -Name "DF-Test-RSV-PS" -ResourceGroupName $ResourceGroup.ResourceGroupName -Location $ResourceGroup.Location

# Modify Vault Storage Redundancy
Set-AzureRmRecoveryServicesBackupProperties -Vault $RSVault -BackupStorageRedundancy LocallyRedundant

NOTE:  All PowerShell code from here on assumes you’ve logged into Azure, set your subscription, registered the backup providers and sorted a resource group

Create a Backup Protection Policy

Now that we’ve deployed a Recovery Vault and configured our storage replication preference, we can crack on and back up a VM…well kinda. We have to create a Backup Protection Policy first. This governs the retention settings for our protected items (VMs).

Although we’re currently interested in the “Azure Virtual Machine” policy, it’s worth being aware that backing up file shares via the Recovery Services Vault is also possible (Currently in Public Preview) and leverages the “Azure File Share” policy. I’ll cover this in part 2 or 3 of the series depending on post length.

Now there is a default policy conveniently created for you, which is named, you guessed it…“DefaultPolicy”. You can have a look at this policy as follows:

• From your Recovery Services Vault blade, select “Backup policies”
• Click “DefaultPolicy”, you’ll now see the policy details on the right (Just need to set the Time Zone)

The retention settings for the Default Policy are:

Policy Type: Azure Virtual Machine
Backup Frequency: Daily @ 23:00 (at least this was the time for my Default Policy, yours may be different)
Retention of Daily Backup: 30 Days

We don’t want to use the Default Policy though, do we? Let’s create a new one.

• Back on the “Backup policies” blade, click “+ Add”
• Under “POLICY TYPE”, select “Azure Virtual Machine”

• Enter a name for your policy under “Policy name”
• Modify the “Backup frequency” as required, set time zone
• Modify or deselect the weekly, monthly and yearly retention points
• Now click “Create”

Using PowerShell

When creating a protection policy using PowerShell, you have to grab the existing default schedule and retention policy objects, modify them as required and use them in your new protection policy creation. That’s a terrible explanation but I’m sure you get it, if not the code should clear it up…hopefully 🙂

We’ll be creating another “Azure Virtual Machine” policy using the same retention settings we used above (with a different name of course). We’re actually going to create two new policies using PowerShell, the long way and the short, kinda cheating way.

First, the long way:

# Variables (Edit as required)
$VaultName = "DF-Test-RSV" # The name of your backup vault
$ScheduleRunTimes = (Get-Date -Date 'Tuesday, March 20, 2018 01:00:00 AM').ToUniversalTime() # Modify date and time as required
$ScheduleTimeOnly = "01:00:00"
$DailyDurationDays = "30" # Number of days to keep daily backup restore points for
$MonthlyDuration = "12"
$MonthlyFormat = "Daily"
$MonthlyDays = [pscustomobject]@{
    'Date' = 0
    'IsLast' = $True
}
$PolicyName = "DF-AzureVM-PolicyPS"

# Get Azure Recovery Vault and set vault context
Get-AzureRmRecoveryServicesVault -Name $VaultName | Set-AzureRmRecoveryServicesVaultContext

#Get default schedule policy object and store in a variable
$SchedulePolicy = Get-AzureRmRecoveryServicesBackupSchedulePolicyObject -WorkloadType "AzureVM"

# Update stored schedule policy object using the values specified in the variables section
$SchedulePolicy.ScheduleRunTimes.Clear()
$SchedulePolicy.ScheduleRunTimes.Add($ScheduleRunTimes)
$SchedulePolicy.ScheduleRunDays = $ScheduleRunDays

# Get default retention policy object and store in a variable
$RetentionPolicy = Get-AzureRmRecoveryServicesBackupRetentionPolicyObject -WorkloadType "AzureVM"

# Update stored retention policy object using same settings as the one we created in the portal
$RetentionPolicy.IsWeeklyScheduleEnabled = $False
$RetentionPolicy.IsYearlyScheduleEnabled = $False
$RetentionPolicy.DailySchedule.DurationCountInDays = $DailyDurationDays
$RetentionPolicy.DailySchedule.RetentionTimes = $ScheduleTimeOnly
$RetentionPolicy.MonthlySchedule.DurationCountInMonths = $MonthlyDuration
$RetentionPolicy.MonthlySchedule.RetentionScheduleFormatType = $MonthlyFormat
$RetentionPolicy.MonthlySchedule.RetentionTimes = $ScheduleTimeOnly
$RetentionPolicy.MonthlySchedule.RetentionScheduleDaily.DaysOfTheMonth = $MonthlyDays

# Create new Backup Protection Policy using above Schedule and Retention Policy Objects
New-AzureRmRecoveryServicesBackupProtectionPolicy -Name $PolicyName -WorkloadType "AzureVM" -RetentionPolicy $RetentionPolicy -SchedulePolicy $SchedulePolicy

You can also use the commands in the above script to modify any existing policy as required.

Now, if we look in the portal (refresh the blade), we can see our new Backup Protection Policy

I’ve marked the “Time Zone” in red as I’ve not found a way to set that via PowerShell yet…if and when I do, I’ll update this guide. In the meantime, update it in the portal and click “Save”

The Quick Way

Being that all we wanted to do was to copy the settings of an existing policy, we could do that in a lot less code:

# Variables (Edit as required)
$PolicyName = "DF-AzureVM-PolicyPS2"

# Grab existing Backup Protection Policy and store in a variable
$ExistingPolicy = Get-AzureRmRecoveryServicesBackupProtectionPolicy -Name "DF-AzureVM-Policy1"

# Create new Backup Protection Policy using above Schedule and Retention Policy Objects
New-AzureRmRecoveryServicesBackupProtectionPolicy -Name $PolicyName -WorkloadType "AzureVM" -RetentionPolicy $ExistingPolicy.RetentionPolicy -SchedulePolicy $ExistingPolicy.SchedulePolicy

Enable/Disable Protection for an Azure VM

We now have everything we need to start backing up an Azure VM, so let’s do that. You’ll need to have deployed a VM in the same region to follow this part of the guide.

• From your Recovery Services Vault blade, select “Backup”
• Select “Azure”, “Virtual Machine” and click “Backup”

• For “Backup policy”, select the policy you created earlier and click “OK”

• For “Select virtual machines”, select the virtual machine you want to protect and click “OK”

• Now click “Enable backup”

The job will take a minute or two to complete. The VM will now be backed up according to the schedule we set in the protection policy earlier. However, we want to test the backup before then don’t we? Of course we do 🙂

• From your Recovery Services Vault blade, select “Backup items”
• Select “Azure Virtual Machine” (Note the “Backup Item Count”)
• Select your VM from the list (The warning is just advising the VM hasn’t been backed up yet)

• This blade provides information of our VM protection status, available restore points etc.
• Click “Backup now”

• Select a date to retain this manual backup till and click “OK” (by default, it’s set 30 days ahead)

• You can check the progress of the backup job by navigating to “Jobs” then “Backup Jobs”

• By clicking on the job, you can see the stage the backup job is currently running

The backup will take a while to complete, so I’m off to grab a coffee.

My backup job took just over an hour to complete, in all fairness though, I did forget I’d deployed it with a 1 TB data drive, and there IS data on it 🙂

Using PowerShell

Enable Azure VM Protection

$ResourceGroupName = "DF-RSVTest-RG"
$VaultName = "DF-Test-RSV" # The name of your backup vault
$VMNameToProtect = "DF-SQLTest1"

# Get Azure Recovery Vault and set vault context
Get-AzureRmRecoveryServicesVault -Name $VaultName | Set-AzureRmRecoveryServicesVaultContext
$ProtectionPolicy = Get-AzureRmRecoveryServicesBackupProtectionPolicy -Name "DF-AzureVM-Policy1"

# Enable Protection of Azure VM
Enable-AzureRmRecoveryServicesBackupProtection -Policy $ProtectionPolicy -Name $VMNameToProtect -ResourceGroupName $ResourceGroupName

Your output should look something like this:

Now we want to trigger the VM backup as all we’ve done thus far is enable protection on a predefined schedule…we’re just jumping the gun a bit here to show the process.

# Get the backup container for our protected Azure VM
$BackupContainer = Get-AzureRmRecoveryServicesBackupContainer -ContainerType "AzureVM" -Status "Registered" -FriendlyName $VMNameToProtect

# Get our Azure VM backup item
$BackupItem = Get-AzureRmRecoveryServicesBackupItem -Container $BackupContainer -WorkloadType "AzureVM"

# Trigger a backup job for our protected Azure VM
$BackupJob = Backup-AzureRmRecoveryServicesBackupItem -Item $BackupItem

# Initiate a wait job which will return an output once the job has completed
Wait-AzureRmRecoveryServicesBackupJob -Job $BackupJob -Timeout 43200

Job done!

NOTE:  Skip the following section if you’re planning on working through the “Restore an Azure VM” section, you can always come back to it at the end when you’re looking to tidy up your subscription.

Disable Azure VM Protection

I’m now going to stop the job and delete the backup data as I plan to use the same VM to enable protection via PowerShell below.

• From your Recovery Services Vault blade, select “Backup items”, then “Azure Virtual Machine”

• Click the context menu … for the relevant VM and select “Stop backup”

• Select “Delete Backup Data” from the drop-down (or Retain if you prefer)
• Type the name of the backup item (You can copy this from just under “Stop Backup” to save you typing it (See screenshot)
• Select a “Reason” and add a “Comment” (if you feel like it)
• Click “Stop backup”

Once that job has completed, we’re in a good position to run through the same process in PowerShell. First things first though, I’m gonna go delete that 1 TB data disk to speed things up a little.

Using PowerShell

Disable Azure VM Protection

As we did within the portal, we’ll be deleting the recovery points for the protected VM while we’re at it.

The PowerShell below assumes you’re still working within the correct vault context, if not, the commands for that are in the previous section.

$VMNameToProtect = "DF-SQLTest1"

# Get the backup container for our protected Azure VM
$BackupContainer = Get-AzureRmRecoveryServicesBackupContainer -ContainerType "AzureVM" -FriendlyName $VMNameToProtect -Status "Registered"

# Get our Azure VM backup item
$BackupItem = Get-AzureRmRecoveryServicesBackupItem -Container $BackupContainer -WorkloadType "AzureVM"

# Disable Azure VM protection and delete existing recovery points
Disable-AzureRmRecoveryServicesBackupProtection -Item $BackupItem -RemoveRecoveryPoints

All going well, your output should look like this:

Restore an Azure VM

Let’s stick with the theme and carry out a restore from the portal first shall we?

After backing up my VM, I’ve downloaded a few files to the desktop so I can easily and visually see the results of my restore when it completes.

• From your Recovery Services Vault blade, select “Backup items”, then “Azure Virtual Machine”

• Click the VM you want to restore

• Select “Restore VM”

• You’ll now be asked to select a “Restore Point” to restore from. If you’re following this guide, you’ll only have one to choose from
• Click “OK”

Now we need to choose the type of restore we want to do, here’s a little more information on the available options:

Restore Type:

• Create Virtual Machine – This will create a new virtual machine using the restored data
• Restore Disks – This allows you to restore the disks only, you can then customise the VM you’ll create with the restore disks via a template created at the time of restore. You can also use this mode if your intention is to delete the original VMs disk(s) and attach the restored disk(s) in their place, therefore reverting the original VM to its previous state at the point it was backed up.

Staging Location:

• This is a filtered list of storage accounts that exist in the same subscription and location as the Vault you’re restoring from. This account is used for temporarily holding data during the restore process, you should create a new one for that purpose…I’m going to use one I have sitting there for this demo though 🙂

In this example, I’m going to restore to a new VM using the “Create virtual machine” option.

• Select “Create virtual machine” and give it a unique name (e.g. VM name with -New on the end)
• Confirm or change the resource group this VM will be created in
• Select the virtual network and subnet this new VM will sit on (I’m putting it on the same network as the VM that I backed up from)
• Select a storage account for your restore “Staging location”
• Click “OK”

• Now click “Restore”

• You can monitor the Restore job progress from “Jobs”, “Backup Jobs”…yeah the restore jobs sit under the backup jobs blade

NOTE:  Keep in mind that the restored VM will have the same resources created for it as exist for the original VM e.g. if the original had a public IP address, the restored VM will have a public IP address of its own.

So my restore completed successfully.

And just for the sake of it, I RDP’d to my restored VM, then hopped from there to the original VM, noting the aforementioned differences on their desktops.

Using PowerShell

For this example, let’s do things little differently. We’ll…

• Delete the original VM
• Restore the VM from backup using the same name and into the same resource group
• We’ll make use of the existing network interface so our restored VM has the same private and public IPs
• Power it up and have a look

I’ve already taken care of the first point from the portal, the rest we’ll do from PowerShell

NOTE:  Remember and set your Recovery Vault context again if you happen to have closed your PowerShell session between steps

$VaultName = “” # The name of your backup vault
# Get Azure Recovery Vault and set vault context
Get-AzureRmRecoveryServicesVault -Name $VaultName | Set-AzureRmRecoveryServicesVaultContext

———————————————————————————-

$ResourceGroupName = "DF-RSVTest-RG"
$VMName = "DF-SQLTest1"
$StorageAccountName = "dfrsvtestrgdiag865" # The name of the storage account you restored your disks to
$DestinationFilepath = "C:\Temp\RestoreVMConfig.json" # Filepath for storing Restored VM Config JSON file

# Get the backup container for our protected Azure VM
$BackupContainer = Get-AzureRmRecoveryServicesBackupContainer -ContainerType "AzureVM" -Status "Registered" -FriendlyName $VMName

# Get our Azure VM backup item
$BackupItem = Get-AzureRmRecoveryServicesBackupItem -Container $BackupContainer -WorkloadType "AzureVM"

# Get Recovery Point (We only have one available hence I've not had to specify a date etc.)
$RecoveryPoint = Get-AzureRmRecoveryServicesBackupRecoveryPoint -Item $BackupItem

# Restore Recovery Point to specified storage account
$RestoreJob = Restore-AzureRmRecoveryServicesBackupItem -RecoveryPoint $RecoveryPoint -StorageAccountName $StorageAccountName -StorageAccountResourceGroupName $ResourceGroupName

# Initiate a wait request which will output when restore job is complete
Wait-AzureRmRecoveryServicesBackupJob -Job $RestoreJob -Timeout 43200

A successful restore looks like this…

All we’ve done so far is restore the disks from our backup, we haven’t created a VM yet…so let’s do that now.

We’ll be using some of the variables we defined above for this next piece.

# Get restore job details
$RestoreJobDeets = Get-AzureRmRecoveryServicesBackupJobDetails -Job $RestoreJob

# The following commands pull out key pieces of info we will use later
$ContainerName = $RestoreJobDeets.Properties.'Config Blob Container Name'
$BlobName = $RestoreJobDeets.Properties.'Config Blob Name'

# Set Azure Storage context and restore JSON configuration file from Storage Account
Set-AzureRmCurrentStorageAccount -Name $StorageAccountName -ResourceGroupName $ResourceGroupName
Get-AzureStorageBlobContent -Container $ContainerName -Blob $BlobName -Destination $DestinationFilepath
$VMConfigObject = ((Get-Content -Path $DestinationFilepath -Raw -Encoding Unicode)).TrimEnd([char]0x00) | ConvertFrom-Json

# Create new VM config
$VM = New-AzureRmVMConfig -VMSize $VMConfigObject.'properties.hardwareProfile'.vmSize -VMName $VMName

# Attach restored OS Disk to VM Configuration
$StorageType = "PremiumLRS"
$OSDiskName = $VM.Name + "_osDisk_" + (New-Guid).ToString().Replace('-', '')
$OSVhdUri = $VMConfigObject.'properties.storageProfile'.osDisk.vhd.uri
$DiskConfig = New-AzureRmDiskConfig -AccountType $StorageType -Location $VMConfigObject.Location -CreateOption Import -SourceUri $OSVhdUri
$OSDisk = New-AzureRmDisk -DiskName $OSDiskName -Disk $DiskConfig -ResourceGroupName $ResourceGroupName
Set-AzureRmVMOSDisk -VM $VM -ManagedDiskId $OSDisk.Id -CreateOption "Attach" -Windows

# Attach restored Data Disks to VM Configuration (if they exist)
if ($VMConfigObject.'properties.storageProfile'.dataDisks) {
    foreach($DataDisk in $VMConfigObject.'properties.storageProfile'.dataDisks) {
        $DataDiskName = $VM.Name + $DataDisk.Name
        $DataVhdUri = $DataDisk.vhd.uri
        $DataDiskConfig = New-AzureRmDiskConfig -AccountType $StorageType -Location $VMConfigObject.Location -CreateOption Import -SourceUri $DataVhdUri
        $DataDisk2 = New-AzureRmDisk -DiskName $DataDiskName -Disk $DataDiskConfig -ResourceGroupName $ResourceGroupName
        Add-AzureRmVMDataDisk -VM $VM -Name $DataDiskName -ManagedDiskId $DataDisk2.Id -Lun $DataDisk.Lun -CreateOption "Attach"
    }
}

# Set VM Network Configuration, assumes the backed up VM nic and public IP object still exist.
$VMNic = Get-AzureRmNetworkInterface | Where-Object Name -Like $VMName*
$VM = Add-AzureRmVMNetworkInterface -VM $VM -Id $VMNic.Id

# Create the new VM using the $VM object
New-AzureRmVM -ResourceGroupName $ResourceGroupName -Location $VMConfigObject.Location -VM $VM

You should now be looking at output that looks similar to this…

Looking in the Portal, everything looks good. My VM has been recreated, has the same public and private IP and as an added benefit, will be backed up again in line with the pre-existing schedule (because I restored it to the same resource group with the same name).

Well actually…that’s not entirely true. When I tried to backup the VM, it failed with a fairly generic error.

So I started looking into it and found that the Azure Backup extension relies on the Azure VM Agent being installed on the VM and working correctly. Now if a VM extension is installed on a VM at the point of backup, when it’s restored it’ll still be installed…BUT NOT ACTIVATED. So knowing that, I wondered if I was seeing similar behaviour with the VM Agent and decided to reinstall it.

This is a manual process that needs to be carried out within the VM.

Fire up an elevated PowerShell ISE console, paste in the following code and run it.

Invoke-WebRequest http://go.microsoft.com/fwlink/?LinkID=394789 -OutFile C:\$env:HOMEPATH\Downloads\AzureVMAgent.msi
cd C:\$env:HOMEPATH\Downloads\
msiexec.exe /i AzureVMAgent.msi

I decided against the /quiet flag as I wanted to know when it completed. Select “Repair” when prompted.

I realised that my VM had the SQL IaaS extension installed and so would need to reinstall that also.

Use the PowerShell session you’ve been using up till now as it’ll have all the necessary variables for this code to work.

# Reinstall VM Extensions, in my case that's the SQL IaaS extension and Azure Backup extensions
Set-AzureRmVMSqlServerExtension -ResourceGroupName $ResourceGroupName -VMName $VMName -Name "SQLIaasExtension" -Version "1.2" -Location $VMConfigObject.Location

I kicked off a backup job for my VM and this time it’s looking much heathier 🙂

There are a couple of things to be aware of going down this route:

• The “Computer name” field in the Azure portal is now blank. This is because during the restore the “OSProfile” settings are blank. This is a limitation of Azure and has been acknowledged by Microsoft. Anyway, it’s more just a pain in the hoop than an actual issue 🙂

• For some reason my “SQL Server Settings” blade is missing. It was there before the restore, so I’ll have to look into this one a little. If I find a solution, I’ll update this part of the post. Looking at the details off the extension confirms that everything is set up and working through so making changes would just need to be done via PowerShell.  I get the feeling it’s because the VM OS disk source is no longer the marketplace image and is now the storage account it restored the disk from…

…but if I’m being honest, this is just a guess.

So in this post, we should have learned the following:

• A little bit about the Azure Recovery Services Vault and how to deploy one
• What a Backup Policy is and how to create one
• How to enable and disable the protection of an Azure VM

That should do it for part 1, join me in part 2 where I’ll be running through a similar process but for on-premises using the Azure Backup agent, chowder!