Getting started with Azure-to-Azure Site Recovery

As you might know, Azure Site Recovery is a great Disaster Recovery solution for on-premises environments. You can use it on pretty much any server you have, ranging from VMware, physical servers and of course Hyper-V. A feature I have wished for since I started doing Azure, is the ability to failover between Azure regions. I’ve also talked to many customers, who asked what mechanisms was available to protect their environments in Azure. Just like on-premises, it is important to have a disaster recovery solution for cloud environments.

I’m happy to say that this feature is now in public preview in Azure Site Recovery. I have been lucky enough to test it for the past few months, and it’s an awesome feature. It’s easy to set up, as there is no need for additional infrastructure in your environment. An agent is installed on the VM, which will replicate data between the regions – that’s all there is to do to start protection. In fact it is very much like the VMware to Azure scenario, but without the configuration server. Below is a guide to get started using ASR – Azure-to-Azure scenario.

You can find the official announcement here:

First of all, create a new Recovery Services vault. Make sure you don’t create it in the source location. In this case my VMs are located in North Europe, and I will do a failover to West Europe:



Next, select Replicate in the top, select the source region (North Europe), and then the Resource Group your VM is in. Note that you can also protect Classic VMs!



On the next screen, select the VMs you want to protect. In this case, this is just a single VM:


On the Settings page, there is a few settings:

  1. Select the region you want to failover to. From North Europe I can choose West Europe, UK South and UK West.
  2. If needed, you can edit the target Resource Group
  3. Make sure you select the correct vnet! It’s rare that you want a randomly created vnet as the destination.
  4. ASR uses a storage account as cache for the data it replicates, you can of course create your own
  5. In case you want to use Availabilty Sets, make sure you select it here. You can’t change this setting!

When you are done, click OK, and then Create Target Resources. This will create any new resources you have chosen.


Now you have to wait a little, while the resources are created. Don’t be fooled, replication is not enabled yet:


When it’s done creating resources, click Enable Replication:


This will start the replication process:


You can follow along in the job view, and see how far it got:


And if you log on to your VM, you can see an agent is being installed. This agent is the InMage agent, which is also used by the VMware scenario.



And under Replicated Items, you can now see the VM replication status:


Just like the other Azure Site Recovery scenarios you can – and should – configure different settings, like subnet and VM size.


That’s all for now. I’ll show failover between regions in anohter post.

Make sure you check out the supported scenarios here:


Moving Azure Managed Disks between regions and subscriptions

I just had a scenario, where a customer is using VMs in Azure, with Managed Disks. Now, due to different events, they wanted to move their VMs to a different region.  Normally that’s an easy task, copying the blobs from one Storage Account to another. It’s actually the same way to do it Managed Disks just a few different steps. Go to your PowerShell prompt!

Using Grant-AzureRmDiskAccess we can create a SAS URL to export our disk from. You can also do this from the portal, but since we’re using PowerShell for the rest…

I started by creating a new Storage Account in the region they wanted to move to – West Europe:

$rgName = “<resource group name>”
$location = “West Europe”
New-AzureRmStorageAccount -Name $storageAccountName -Location $location -SkuName Premium_LRS -ResourceGroupName 

Next I needed the keys for this Storage Account:

$saKey = Get-AzureRmStorageAccountKey -ResourceGroupName $rgName -Name $storageAccountName

Next, create a Storage Context, which is just a PowerShell object to encapsulate credentials for a Storage Account:

$storageContext = New-AzureStorageContext –StorageAccountName $storageAccountName -StorageAccountKey $saKey[0].Value 

And a container for the vhd files:

New-AzureStorageContainer -Context $storageContext -Name vhds

From there I can create the SAS URL for my Managed Disk:

$diskName = “<diskname>”
$sas = Grant-AzureRmDiskAccess -ResourceGroupName $rgName -DiskName $diskName -DurationInSecond 3600 -Access Read 

Now I have 1 hour to copy my disk, which is fine for me. Using Start-AzureStorageBlobCopy I can then use the SAS URL I just got as my source, and the Storage Context to access the destination:

Start-AzureStorageBlobCopy -AbsoluteUri $sas.AccessSAS -DestContainer vhds -DestContext $storageContext -DestBlob $diskName

This will finish *quick*, but don’t be fooled. The command only starts a job to copy the blob. To get a status, you can use:

Get-AzureStorageBlobCopyState -Context $storageContext -Blob $diskName -Container vhds

It will output something like:

CopyId            : 38ad189f-9c91-4d2d-ba42-2eb248a42d37
CompletionTime    :
Status            : Pending
Source            :
BytesCopied       : 817053696
TotalBytes        : 137438953984
StatusDescription :

Now it’s just a matter of waiting for it to finish, and you can create the VM in the destination region. All of the above can also be used to move between subscriptions, a feature that is not yet available for Managed Disks.