Instant Recovery Point and Large Disk Azure Backup support

With everything that happens on Azure, and following what has been announced of the increase of the size of the disk in Azure, from 1TB to 4TB, the only missing part of this was the support of Azure Backup to be able to backup and recovery those volumes.

But what changed? Today the Azure Backup job consist of the Two phases:

  1. Taking a VM snapshot
  2. Transferring the VM snapshot to Azure Backup Vault

So, depending how many recovery points you configure on your policy, it will only be available a recovery point when both phases are complete. With the introduction of Instant Recovery Points feature on Azure Backup, a recovery point is created as soon as the snapshot is finished. That means that you RPO and RTO can be reduced significantly.

You can use the same restore flow on Azure Backup, to restore from this instant recovery point. For this you can identify the recovery point from a snapshot in the Azure Portal, using the Snapshot as a recovery point type. Once the snapshot is on the Azure Backup Vault, the recovery point type will change to Snapshot and Vault.

By default, the snapshots are retained for 7 days. This will allow you to complete restore way faster, from these snapshots and at the same time, reducing the time required to copy the backup from the vault to the storage account where you want to restore.

Instant Recovery Point Features

Please note that all the features are not yet available, this is still on preview

  1. Ability to see snapshot taken as part of backup job to be available for recovery without waiting for data transfer to complete.Note: that this will reduce the wait on snapshot to be copied to vault before triggering restore. Also, this will eliminate the additional storage requirement we have for backing up premium VMs.
  2. As part of above feature, we will also enable some data integrity checks. This will take some additional time as part of backup. We will be relaxing these checks as we move and so it will reduce backup times.
  3. Support for 4TB unmanaged disks
  4. Ability to use original storage accounts (even when VM has disks are distributed across storage accounts). This will make restores faster for a wide variety of VM configurations.Note: this is not same as overriding the original VM.
  5. Ability to do above things for managed disks.

 

Is important to know that when you enable this feature you will notice the following:

Since the snapshot are store on the Azure Backup vault, to reduce the recovery point and reduce the restore time, you will see some increase on the storage cost, corresponding to the snapshots that are store for 7 days (if you go with the defaults).

When you are doing a restore from a snapshot recovery point for a Premium VM, you will might see a temporary storage location being used while the VM is created, as part of the restore.

Once you enable the preview feature, you can’t revert, that means you can go back and all the future backups will use this feature.

If you have the VMs with Managed Disks, this feature is not support yet. Although if you have VMs that are using Managed Disks, is supported, but they will be using the normal backup (the Instant Recovery Point will not be used, in this case). Virtual Machines migrations from unmanaged and managed are not supported.

If you want to try this feature, run the following commands:

  1. Open PowerShell with elevated privilege
  2. Login to your Azure Account
    Login-AzureRmAccount
  3. Select the subscription you want to enable the Instant Recovey Point feature
    Get-AzureRmSubscription –SubscriptionName “<SUBSCRIPTION_NAME>” | Select-AzureRmSubscription
  4. Register for the preview
    Register-AzureRmProviderFeature -FeatureName “InstantBackupandRecovery” –ProviderNamespace Microsoft.RecoveryServices

 

Cheers,

Marcos Nogueira
Azure MVP

azurecentric.com
Twitter: @mdnoga

Disaster Recovery solution within Azure – Part 2

On the previous post (see here), I create the Recovery Service vault that is required to configured the Site Recovery infrastructure to protect the workloads, in order to have a Disaster Recovery solution within Azure. In the post, I will show how you can protect your workloads (Azure VMs) from one region into another region.

First step is to prepare the infrastructure. Azure Site Recovery have many scenarios that you can protect the workloads, but in these case, I will only cover the Azure VM protection to another region.

As mention on the previous blog post, my workloads are running on the West US 2 region. After creating the Recovery Services vault on East US 2 region, I need to prepare the infrastructure.

To step up the infrastructure follow the steps:

  1. On the Recovery Services vault, click on Site Recovery, under GETTING STARTED
  2. It will open another blade. Click on Prepare Infrastructure

  3. Select Azure – PREVIEW, under Where are your machines located?
  4. Make sure that you select To Azure on Where do you want to replicate your machines to?
  5. Click OK

  6. Fill all the details required:
    1. Source Location – is the region where your workloads are running
    2. Azure virtual machine deployment model – make sure that you select Resource Manager
    3. Source resource group – is the recourse group where your workloads are running
      NOTE: If you have more than one resource group on the same region, you must run this setup again, to add more workloads located on another resource group.
  7. Click OK to proceed
  8. Select the workloads that you want to protect.
  9. Click OK

  10. On the Configure settings blade, click Create target resources button to conclude the preparation of the infrastructure.
    NOTE: Under Target location, by default choose the location where you create the Recovery Services vault, although you can select another region where do you want to replicate too. It’s not recommend that you choose the location where your workloads are running.

  11. If you do want to change the default settings, then you can click on Customize. Otherwise you can skip to the last step.
    There are two different settings that you can customize:

    1. Resource group, Network, Storage and Availability sets – On this setting you will configure witch resource group, network, storage account and availability set your workload will run, when your failover the virtual machine.
    2. Replication policy – is where you change the name of the replication policy, RPO and the frequency of the replication.
  12. If you want to change any of the following setting:
    1. Target resource group – This is the Resource group where your workload will run in case of failover. On the drop down, list you will see only the resource group available on the region that you previous select. Although you can either create a new (by default) or use an existing one.
    2. Target virtual network – This is where you can define witch network your workload will run in case of failover. On the drop down, list you will see only the networks available on the region that you previous select. Although you can either create a new (by default) or use an existing one.
    3. Storage accounts
      1. Target Storage – This is where your workload will be replicated too. On the drop down, list you will see only the storages accounts available on the region that you previous select. Although you can either create a new (by default) or use an existing one.
      2. Cache Storage – This is where your workload will be replicated too. On the drop down, list you will see only the storages accounts available on the region that you previous select. Although you can either create a new (by default) or use an existing one.
    4. Availability sets – This is availability set that your workload will be running in case of failover. On the drop down, list you will see only the availability sets available on the region that you previous select. Although you can either create a new (by default), use an existing one or choose not to set an availability set (Not Applicable option).
  13. After you change the settings that you want, click OK

  14. If you want to change the policies setting, these are your options:
    1. Choose by creating a new policy or an existing one.
      NOTE: If you are running these for the first time, it’s recommended that you create a new policy. Although if you are running for the second or more times, you can either choose an existing policy (if the settings are the same) or create a new policy, if the settings are different. It’s not recommended that you create new policies with the same settings.
    2. Name – This is where you can change the name of the policy
    3. Recovery point retention – This is where you can configure how long do you want to keep each recovery point.
    4. App consistent snapshot frequency – This is where you can choose the frequency of the replication.
  15. After you change the settings that you want, click OK

  16. Click Enable replication button, to start the workload protection.

  17. After the configuration is done. Azure will start to replicate the workload from on region to another. The time of the replication it will depend on the size of the disks attached to the workload.

All this process is live. That means you don’t have any downtime while Azure is doing the initial replication.

Cheers,

Marcos Nogueira
Azure MVP

azurecentric.com
Twitter: @mdnoga

Disaster Recovery solution within Azure – Part 1

We know that in the Public Cloud, special Azure, we are cover by the SLA. Although some organizations like to be redundant where it comes to critical workloads. In this post I will cover how you can setup a Disaster Recovery solution within Azure.

In this case I have all my critical workloads running on West US 2 region and the East US 2 is my disaster recovery site.

The first step is to create the Recovery Vault. The Recovery Services Vault is feature inside Azure that makes everything work, as also known by Azure Site Recovery. You can have as many Recovery Services Vaults as you want. Each Recovery Services vault will have its own storage account associated, that means if you create more than one Recovery Service vault you will have more than one storage accounts.

When you create a Recovery Services vault, you need to choose the region where you want to store those workloads. That means the Recovery Services vault is acting as your destination, because of this it’s not recommended to create on the same region that your workloads are running.

To create the Recovery Services vault, follow the steps:

  1. Click on the Create Recovery vaults button
  2. Insert the following details
    1. Name
    2. Select the subscription that you want to create the Recovery Services Vault
    3. Create or Select an existing Resource Group
    4. Choose your location (this need to be a different region of the workloads that you want to protect)
  3. Click on the Create.
  4. After the creation of the Recovery Services vault, you just create the infrastructure require on Azure to setup all the services need.

There are some considerations when you create a Recovery Services vault to protect you workloads within Azure (this considerations are only for this scenario).

  1. At this present moment, you only create the infrastructure that supports Azure Site Recovery and Azure Backup. You are not done yet. The next step is to configure either or both services (Site Recovery and Backup).
  2. If you want to use the Recovery Services for Site Recovery, you need to prepare the infrastructure that will support that. In this case, you need to decide what type of workloads you want to protect from where to Azure. If you want to protect workloads within Azure (i.e between regions), your source workloads (where they are running) should be in a different region. For optimal utilization try to use the “direct” DR Azure site (EastóWest or North óSouth).
  3. You can protect different regions to the same Recovery Service vault. Although the workloads should not be running on the region, that your Recovery Services is created.
  4. You don’t need to setup any VNet-to-VNet between the regions. Recovery Services uses the backbone of Azure, to connect to the workloads that you want to protect.

 

Cheers,

Marcos Nogueira
Azure MVP

azurecentric.com
Twitter: @mdnoga

Implementing Azure Site Recovery – Part 4 – Managing and Automating

After I post the series of Azure Site Recovery (ASR) Planning considerations, I received an enormous quantity of feedback how It should be implemented, following those considerations. So, this is the last post of a series of 4 (see the first post here, second here and third here), about how to implement Azure site recovery based protection on the scenarios describe on the previous series posts.

If you want to visit the series where I talked about the ASR Planning Considerations, you can do it by select the right scenario:

After an on-premises computer appears in the portal with the Protected status, you can perform test failovers, planned failovers, or unplanned failovers. When you do so, the sequence of events differs, depending on the type of failover you choose:

  • In case of a test failover, you specify the Azure virtual network you want to fail over to. To prevent any possibility of impacting the production environment, this should be an isolated network. Site Recovery provisions a new Azure virtual machine in the virtual network by using replicas of the virtual disks that are residing in the Azure storage account. The protected virtual machine stays online. After you complete your testing, Site Recovery automatically delete the Azure virtual machine.
  • In case of a planned failover, Site Recovery shuts down the protected virtual machine to prevent the possibility of data loss. Next, it provisions the corresponding Azure virtual machine by using replicas of virtual disks residing in the Azure storage account. It also places the new virtual machine in a commit pending state. You must perform the commit action to complete the failover. The commit removes any existing recovery points in Azure storage.
  • In case of an unplanned failover, Site Recovery provisions the replica Azure virtual machine by using replicas of virtual disks residing in the Azure storage account. You can instruct Site Recovery to attempt to synchronize protected virtual machines and shut them down, but, in this scenario, such an action might not be possible. Alternatively, you can specify to use the latest recovery point available in Azure storage. Site Recovery will place the newly-provisioned Azure virtual machine in a commit pending state. You must perform the commit action to complete the failover. The commit removes any existing recovery points in Azure storage.

Note: With all three types of failover, if you enabled data encryption when you are running the Azure Site Recovery Provider setup, you must provide the encryption certificate as part of a failover.

When performing planned or unplanned failover, once your primary site is back online, you should protect the Azure virtual machines and establish reverse replication. This will allow you to fail back to the on-premises location without data loss.

Recovery plans

While it is possible to perform failover and failback of individual protected computers, it is more beneficial from the standpoint of business continuity to orchestrate disaster recovery of multiple computers. Site Recovery supports this scenario by allowing you to create recovery plans.

A recovery plan consists of one or more recovery groups, which serve as logical containers of protected virtual machines. You arrange groups in a sequence that dictates the order in which Site Recovery failover and failback bring the protected virtual machines online. Within this sequence, you can add pre and post actions. Each action can represent a manual recovery step or an Azure Automation runbook. By using Azure Automation, you have the option to fully automate your disaster recovery. You can also use it to provision and configure additional Azure components, such as load balancers.

Site Recovery uses a context variable to pass several parameters to the Azure Automation runbook. You can use these parameters to customize runbook activities. These parameters include:

  • RecoveryPlanName: Name of the Site Recovery plan.
  • FailoverType: Type of failover (test, planned, or unplanned).
  • FailoverDirection: Direction of the failover (from the primary site to Azure or from Azure to the primary site).
  • GroupID: Identifier of a group within the recovery plan.
  • VmMap. Collection of virtual machines within the group.

Cheers,

Marcos Nogueira
azurecentric.com
Twitter: @mdnoga

Implementing Azure Site Recovery – Part 3 – For VMware Virtual Machines and physical server

After I post the series of Azure Site Recovery (ASR) Planning considerations, I received an enormous quantity of feedback how It should be implemented, following those considerations. So, this is the third post of a series of 4 (see the first post here and second here), about how to implement Azure site recovery based protection on the scenarios describe on the previous series posts.

If you want to visit the series where I talked about the ASR Planning Considerations, you can do it by select the right scenario:

In this post, you will step through a sample implementation of Site Recovery with the on-premises primary site and the secondary site that is residing in Azure. Your intention is to protect on-premises VMware virtual machines and physical servers. In this scenario, you are using VMware vCenter to manage your vSphere hosts. Your implementation will consist of the following tasks:

  1. Creating an Azure virtual network in your Azure subscription in the Azure region that meets your disaster recovery objectives.
  2. Creating an Azure storage account in the same subscription and the same region as the Azure virtual network.
  3. Setting up an account on the vSphere host or vCenter server to facilitate automatic discovery of VMware virtual machines.
  4. Preparing the configuration server to allow outbound access to the Azure URLs listed in the previous lesson and installing vSphere PowerCLI 6.0.
  5. Creating a Recovery Services vault in the same subscription and the same region as the storage account and the virtual network.
  6. Specifying the protection goal of your implementation. When using the Azure portal, this is the first task in Step 1: Prepare Infrastructure of the GETTING STARTED Wizard and involves answering the following two questions:
    1. Where do you want to replicate your machines? Select the To Azure option.
    2. Are your machines virtualized? Select the Yes, with VMware vSphere Hypervisor option.
  7. Setting up the source environment. This consists of the following steps:
    1. Adding the configuration server entry that is representing your on-premises configuration server.
    2. Downloading the Site Recovery Unified Setup installation file and the Recovery Services vault registration key to the configuration server. Run the installation by using the newly downloaded setup file and, when you receive a prompt, provide the vault registration key. As part of the installation, you will set up an instance of MySQL Server and specify its admin credentials. You will also be able to designate the port TCP 9443 on which the server will send and receive the replication data. You can modify it if needed.
    3. Running CSPSConfigtool.exe on the configuration server and adding the account you set up in step 3 that will perform automatic discovery of VMware virtual machines.
    4. Adding the vCenter server and vSphere host entries that are representing your on-premises virtualization environment in the Azure portal.
  8. Setting up the target environment. As part of this step, you must specify the post-failover deployment model. In this walkthrough, you will choose Resource Manager, but Site Recovery also supports the classic deployment model. At this point, you will also have a chance to verify that you can use the virtual network and the storage account that you created earlier to host replicas of protected virtual machines and their disks. You have the option to create the virtual network and the storage account if this is not the case.
  9. Setting up replication settings. This step involves configuring a replication policy and associating it with the configuration server you added in step 7.1. The policy includes settings such as copy frequency, recovery point retention, app-consistent snapshot frequency, and initial replication start time.
  10. Confirming that you have run the Capacity Planner. The wizard will include a drop-down list from which you need to select Yes, I have done it in order to successfully complete the Preparing infrastructure step.
  11. Selecting the VMware virtual machines and enabling their replication. This consists of the following steps:
    1. Installing the Mobility service on the virtual machines you intend to protect. You can perform the installation by initiating it from the process server, either by using your existing software deployment solution such as System Center Configuration Manager or doing it manually.
    2. Configuring Step 2: Replicate Applications of the GETTING STARTED Wizard in the Azure portal. You must specify the vCenter server or vSphere host you selected in step 7.4. In addition, you must select the process server if you installed it on a computer other than the configuration server. You also must select the Azure virtual network and the storage account you want to use to host replicas of protected virtual machines and their disks. In addition, this step involves selecting the VMware virtual machines that you want to protect. For each virtual machine, you can designate the account that the process server will use to install the Mobility service. You can also select disks that you want to exclude from replication and specify the size of the replica Azure virtual machine. Finally, you also must choose a replication policy that you want to take effect in this case.

Cheers,

Marcos Nogueira
azurecentric.com
Twitter: @mdnoga