Operations Management Suite (OMS): Protection & Recovery

Introduction

In this chapter, we will explore the backup and recovery options for both on-premises and Azure-based workloads that leverage Microsoft Azure. Before we delve into your Azure-integrated backup options, we will cover some terminology and concepts related to data and application backup and recovery. In this chapter, you will learn about the various options available, including:

• Onboarding in OMS
• Technology and Concepts
• System Center Data Protection Manager (DPM)
• Microsoft Azure Backup Server (MABS)
• Azure Backup
  • Backing Up Azure VMs
  • Backing Up On-Premises VMs
• Azure Site Recovery (ASR)
• Backing Up SQL Workloads to Azure Blob Storage
• Automated SQL Backup in Azure VMs
• 3rd Party Azure-Integrated Backup

Objectives for this chapter

The capabilities of Azure Backup and ASR are huge features and are always evolving. Rather than repeating step-by-step documentation that becomes quickly outdated, this chapter will focus on the following objectives:

• Provide a quick study on feature capabilities
• Explain how to identify which option(s) suit your use cases
• Point to current step-by-step documentation
• Offer recommendations and best practices for each feature

We will start with a look at OMS integration with Azure Backup and ASR.

Onboarding in OMS

At present, the integration between OMS (via the OMS Protection and Recovery offering) and these two features is pretty light. OMS really only serves as a single pane of glass for navigating to Azure Backup and ASR in the Azure portal, as well as a licensing vehicle. You can license Azure Backup and ASR together through OMS Protection and Recovery for a single monthly per-node fee (currently $30 USD/node/month). Pricing details are available at http://bit.ly/2lU1j6k.

Note: Technically, if you only require Azure Backup or ASR, you can buy them directly in the Azure portal. When purchased standalone, Azure Backup is billed based on the amount of storage consumed. ASR is priced per node. Note that the two services, when purchased separately standalone are more expensive than purchasing through OMS.

To enable both the Azure Backup and Azure Site Recovery features from the OMS Portal, perform the following steps:

1. In the OMS Portal, go to the Solutions Gallery.
2. Click Protection & Recovery.
3. Click Add.

At this point, both the Backup and Site Recovery solutions will reflect "Solution Requires Additional Configuration". The next step for both the Backup and Azure Site is to create a new Azure vault for the given feature.

For example, if you click on the Azure Site Recovery solution in the OMS Portal, you will see a link labeled "Create a new Azure Site Recovery Vault", as shown in Figure 1.

FIGURE 1. AZURE SITE RECOVERY SETTINGS

Likewise, both Backup and ASR will present a "Select an account" drop-down where you can select an existing vault if you have already created one. Once you select a vault, statistics will be presented in the tile in the OMS Portal.

When you click on the "Create a new…" link to create a vault for either solution, you will be taken from the OMS Portal to a new tab on the appropriate screen in the Azure Portal. While one can expect there will be deeper integration in the future, this is the extent of the integration between OMS and the Backup and ASR solutions today.

Terminology and Concepts

When discussing recovery services, it is important to distinguish backup services from disaster recovery (DR). Each of them is crucially important to a business, but they are very different in their goals and approaches. Backups are designed as safeguards for data loss while disaster recovery processes are designed to ensure business continuity.

Before we get into the Azure Backup and ASR solutions in greater depth, we will briefly touch on some concepts related to backup and disaster recovery that will influence your configuration decisions.

Backup

Backup procedures are designed to serve one purpose: prevent data loss in the event of a catastrophic failure. In the event of a failure, data can be retrieved and restored to a separate location from the original source.

Two metrics typically govern backup processes: Recovery Point Objective (RPO), and Recovery Time Objective (RTO). The RPO defines how frequently and how many backups are taken, and the RTO defines how long it takes to restore the data to a fully functional state. For example, an RPO might be defined to require a SQL server to be backed up once a day, and those backups kept for the last 14 days before they expire and space is reclaimed. It might also require sending a full backup offsite once a month. However, the RTO might be defined to require that any data from the last 14 days needs to be restored within 30 minutes to avoid downtime, while data that needs to be restored from two months ago, needs to be restored within 24 hours.

Disaster Recovery

Disaster Recovery is designed to serve a larger goal: which is to ensure the business is able to continue functioning in the event of a disaster. For this reason, disaster recovery tends to be tightly intertwined with Business Continuity Planning (BCP), as businesses today are unable to function without the technology systems as they have come to rely on in place and functioning.

When it comes to disaster recovery, there is one metric that is critical: the RTO. Since the business needs to continue functioning, the RTO needs to be as short as possible. For this reason, services deemed critical to the business's success are often architected from the ground up to be highly available (HA). However, solutions that are architected to be highly available are typically geographically constrained. That is, they are typically built within the same data center due to latency or throughput requirements. This is less than ideal in a disaster, where the entire data center might be entirely offline in the event of a catastrophic failure (perhaps even including the backup systems!).

Availability is typically defined in '9s'. Three '9s' availability requires 99.9% uptime, while five '9s' availability requires 99.999% uptime. There is a corollary to this, however: the more '9s' are required, the more expensive a solution becomes. There is a delicate tradeoff in which disaster recovery RTO is balanced against budget constraints.

In BCP, selecting a failover site location that is far enough away from the primary site is very important. While there is no single correct answer, whether it is winter storms, hurricanes, power outages, or terror threats, you need to make sure that it is very unlikely that a single event could take down both sites. Fortunately, with regional data centers around the world, it is easy to achieve the necessary distance when leveraged as a disaster recovery site.

Which Azure Backup components should I use?

If you are not sure which Azure Backup component works for your needs, it may help to weigh your options based on a few simple questions:

• What data or application do I need to protect?
• How often do I need to take backups?
  • What and how much data do I need to recover?
• How often? And how quickly?
• What are my backup retention requirements?

To help sort through your options, the two tables below outline the capabilities and limitations of four different protection options:

• Azure Backup (MARS) agent. An agent you deploy to Windows systems that enables backup files and folders directly to an Azure Backup Vault. The agent is already present on VMs created from the Azure gallery. This is going to be important for recovering individual files and folder.
• System Center 2016 Data Protection Manager (DPM). This is the enterprise solution that has been around since 2006, with features that support on-premises and hybrid recovery strategies, with support for disk-to-disk, disk-to-tape backup, as well as disk-to-disk-to-cloud. You cannot implement disk-to-tape backup without DPM.
• Azure Backup Server (MABS). A lightweight DPM equivalent version for Azure customers, but does not offer disk-to-tape backup, as it is cloud-focused.
• Azure IaaS VM Backup. Azure Backup includes an agentless backup option of Azure VMs, using a backup extension, designed for VM-level backups.

What is protected? Where are backups stored?

What you have to protect and where backups will be stored, are two good opening questions. Your RPO and RTO requirements will factor strongly in determining which of these options is best. The answers for each option are shown in Table 1.

TABLE 1. PROTECTION AND BACKUP STORAGE

Benefits & Limitations

As you can see in table 1, some of our options have overlapping capabilities, so we need to ask some additional question to determine which option is best for our circumstances.

TABLE 2. BENEFITS AND LIMITATIONS

Do I need DPM or MABS?

Before we get into the pure Azure scenarios like Azure IaaS VM protection and recovery, it is helpful to be clear about the capabilities and limitations of DPM and MABS, so you know when and where one or the other may be required.

DPM Capabilities

DPM is important for some on-premises or multi-site scenarios, including:

Broad support for Microsoft workloads

DPM was originally designed to protect Microsoft enterprise workloads from Windows Server, SQL, SharePoint, Exchange, and Hyper-V with support for Windows clients thrown in for good measure. In recent years, Microsoft has added support for Linux VMs hosted in Hyper-V, albeit only with file system-level consistency.

Additional Reading: Backup consistency level, including crashconsistent, file system consistent, and application-consistent are described in detail in a table in "Plan your VM backup infrastructure in Azure" on the Microsoft website at http://bit.ly/2m5AnAf.

For detailed workload support information, see the DPM support matrix in "Table 3. DPM Supported Scenarios" later in this chapter.

Disk-to-tape backup

None of the other solutions covered in this chapter cover backup to tape.

Site-to-site replication

One of the features of DPM is that it allows replication of one DPM server to another. This capability allows the DPM server itself to be redundant so that in the event a DPM backup server fails, it can be restored from the other, preferably a DPM server in another physical site. It is a 'backup for your backup', enabling transport of backups offsite, providing a disaster recovery capability.

System Center integration

DPM is the only solution covered here that offers any integration with Microsoft System Center components, such as integrated monitoring and management in System Center Operations Manager (SCOM).

DPM integration with Azure Backup

Not every business is large enough to have multiple data centers to which they can replicate their backup data through DPM. In some cases, businesses are moving to a cloud-first strategy, with no on-premises data center to replicate their cloud backups. This poses a disaster recovery challenge for these customers. Fortunately, Azure Backup offers a backup target for DPM. By installing a backup agent on the DPM server, protected sources can be replicated to Azure, ensuring that should the DPM server be lost in a catastrophic event, the backups are still available.

Backups to Azure are secured through encryption. A management certificate (generated outside of Azure) is used to encrypt API communications to Azure Backup, and the backup data itself is encrypted with a passphrase (that is also generated on-premises). This ensures that the communication channel is always protected and that the data at rest is always protected and are only accessible by you.

STEP-BY-STEP: For step-by-step configuration guidance, see "Configure Azure Backup to quickly and easily backup Windows Server" on the Microsoft website at https://msdn.microsoft.com/en-us/library/azure/dn337332.aspx

Microsoft Azure Backup Server (MABS)

Recently Microsoft came up with an initiative called Microsoft Azure Backup Server which is a DPM equivalent version for Azure customers. Azure Backup Server is functionally equivalent to DPM, with several notable exceptions, most importantly:

• MABS cannot be integrated with System Center components.
• MABS does not support tape backup.
• MABS requires an active Azure subscription.

Like DPM, MABS also support application workload backups of Microsoft SQL Server, Hyper-V VMs, SharePoint Server, Microsoft Exchange and Windows Clients. This solution is ideal for customers who do not own System Center licenses to implement DPM, but owns an Azure subscription and/or planning to leverage Azure for data backups.

MABS is supported in both on-premises and in Azure IaaS VMs. If you deploy MABS onpremises and your backup strategy includes disk-to-disk backups only, MABS is totally free. MABS is a free product and you are only charged for the storage usage of the Azure Backup vault consumed for the backups if you are planning to implement a disk-to-disk backup on-premises, in addition to a disk-to-cloud backup strategy for long-term retention. Basically, you need MABS at a minimum to implement a disk-to-disk strategy on premises.

STEP-BY-STEP: For a step-by-step guide on implementing Microsoft Azure Backup Server, see "Preparing to backup workloads to Azure with DPM" on the Microsoft website at https://azure.microsoft.com/en-us/documentation/articles/backup-azure-dpm-introduction/

Limitations of DPM with Azure VMs

While most of the application tier workloads have no change as they move to Azure Infrastructure-as-a-Service (IaaS), some of the sources that DPM can back up on-premises by their very nature cannot be backed up from Azure. For an example, Azure VMs are running on hypervisors, but tenant VMs are abstracted away from the hypervisor and DPM cannot access them at a hypervisor level. Azure SQL is a distributed, highly available SQL service that is also by its very design abstracted away so that tenants are unable to access the underlying resources (as Azure SQL is Platform-as-a-Service (PaaS) offering). This prevents DPM from backing up Azure VMs (at the VM level) or Azure SQL Tables, but note that you can back up an Azure VM at the OS level, as well as applications hosted in the VM.

Table 3 below outlines the Azure IaaS resources that are (and are not) supported by the latest version of DPM or MABS for recent versions Windows and enterprise workloads.

Need info on legacy versions of Windows and server applications (older than 2 versions)? See the full support matrix at https://technet.microsoft.com/en-us/library/jj860400(v=sc.12).aspx.

TABLE 3. DPM SUPPORTED SCENARIOS

In the next section, we will look at the native data protection capabilities of Azure in the Azure Backup feature.

Azure Backup

Of course, not everyone has DPM in place for backups. Azure Backup is a feature that enables protection of both Azure IaaS VMs, as well as physical and virtual systems in your corporate data center. As you will see next, the process for protecting Azure VMs is streamlined versus the steps for on-premises VMs.

Features and Limitations

Today, there are a few capabilities and limitations in Azure Backup to be aware of:

• Supports client operating systems Windows 7 and later.
• Supports server operating systems Windows 2008 R2 and later.
• Supports VM backup with application-level consistency, but only supports VM, file and folder backups.
• Supports backup and recovery of Azure IaaS VMs running supported versions of Linux, but only with file system-level consistency.
• Cannot protect removable media, read-only volumes, network shares, BitLocker protected volumes and non-NTFS volumes.
• Protects volumes up to 1 TB.

Backup Azure VMs

Azure Backup for Azure VMs is a feature that makes protecting your Azure VMs a relatively simple task. Azure Backup for Azure VMs provides application-consistent backups for both Windows and Linux VMs with no downtime.

High-level Steps

The high-level steps to configure Azure Backup to protect Azure VMs are:

• Create an Azure backup vault (classic) or recovery services vault (IaaS v2) in the same Azure regional data center as the VMs you wish to backup.
• Run a VM discovery (which identifies unprotected VMs in the same Azure regional data center as your backup vault)
• Register the VMs that will be protected (backed up), including the backup policy
• Set the backup and retention policy

Because this all runs as-a-service, you can perform all the configuration in the Azure portal with no backup infrastructure required.

STEP-BY-STEP: For step-by-step instructions for configuring protection of IaaS v2 VMs, see "Backup Azure virtual machines to a recovery services vault" at https://docs.microsoft.com/en-us/azure/backup/backup-azure-arm-vms.

How it works

We should start with a brief description of how the service works "under the hood". To back up an Azure VM, first, you need a point-in-time snapshot of the data. The Azure Backup service initiates the backup job at the scheduled time and triggers the backup extension to take a snapshot. The backup extension coordinates with the Microsoft VSS service in the Azure VM to achieve consistency (Windows VMs only). Once consistency is reached, the backup extension invokes the blob snapshot API of the Azure Storage service to get a consistent snapshot of the disks of the virtual machine (VM), without having to shut it down.

After the snapshot has been taken, the data is transferred by the Azure Backup service into the backup vault. The service handles the job of by identifying and transferring only the blocks that have changed from the last backup – making the backups storage very efficient. When the data transfer is completed, the snapshot is removed and a recovery point is created. You can view this recovery point in the Azure management portal.

Prerequisites

The primary prerequisite to configuring backups is creating a backup vault or recovery services vault. The Azure Backup service has two types of vaults - the Backup vault and the Recovery Services vault. The Backup vault came first. Then the Recovery Services vault came along to support the expanded Resource Manager deployments. Microsoft recommends using Resource Manager deployments unless you specifically require a Classic deployment.

TABLE 4. AZURE VAULT TYPES

Create a Backup Vault

You can use the "Quick Create" option to create an Azure backup vault in few clicks, as you no longer have to create and upload an x.509 v3 certificate. In the Azure Management Portal, click New  Recovery Services  Backup Vault  Quick Create, as pictured in Figure 2.

FIGURE 2. AZURE BACKUP VAULT "QUICK CREATE" OPTION

In case you need it, the step-by-step process for configuring a backup vault in the Azure management portal is available as a video guide on the Microsoft website in "Getting Started with Azure Backup 1 of 3 - Set up a backup vault on Azure" at https://azure.microsoft.com/en-us/documentation/videos/getting-started-with-azurebackup-1-of-3-set-up-a-backup-vault-on-azure/

Calculating data and cost protected instances

Azure VMs that are backed up using Azure Backup will be subject to Azure Backup pricing. The Protected Instances calculation is based on the actual size of the VM, which is the sum of all the data in the VM, excluding the resource (OS) disk. You are not billed based on the maximum size supported for each data disk attached to the VM but on the actual data stored on the data disk. Similarly, charges for the backup storage are also based on the amount of data stored with Azure Backup, which is the sum of the actual data in each recovery point.

The billing does not start until the first successful backup is completed. At this point, the billing for both storage and protected instances will begin.

For a complete reference on Azure backup pricing, you can refer "Backup Pricing" in Microsoft Azure documentation at https://azure.microsoft.com/enus/pricing/details/backup.

Back up Azure IaaS v2 VMs

The high-level steps for backing up Azure IaaS v2 VMs are:

• Configure the backup vault or recovery services vault
• Configure the backup job (from the VM management blade in the Azure portal)
• Set backup goal, policy, and items to protect

The backup extension is installed by the Backup service whether the VM is running. A running VM provides the greatest chance of getting an application-consistent recovery point. However, the Azure Backup service continues to back up the VM even if it is turned off, and the extension could not be installed. This is known as Offline VM. In this case, the recovery point will be crash consistent.

STEP-BY-STEP: For step-by-step instructions for configuring protection of IaaS v2 VMs, see "First look: Protect Azure VMs with a recovery services vault" at https://docs.microsoft.com/en-us/azure/backup/backup-azure-vms-first-look-arm.

Back up Classic Azure IaaS VMs

The high-level steps for backing up Classic Azure IaaS VMs are:

1. Create a backup vault or identify an existing backup vault.
2. Use the Azure Classic portal to discover and register the virtual machines.
3. Install the VM Agent.
4. Create the policy for protecting the virtual machines.
5. Run the backup.

STEP-BY-STEP: For step-by-step instructions for configuring protection of Classic Azure IaaS VMs, see "First look: Backing up Azure virtual machines" at https://docs.microsoft.com/en-us/azure/backup/backup-azure-vms-first-look.

Security Features for Hybrid Backups

To protect data against cyber security issues like intrusion, ransomware and data exfiltration, Microsoft has added a number of security features to protect data in hybrid backup scenarios. The security features are designed to support three pillars

• Prevention - An additional layer of authentication is added whenever a critical operation like Change Passphrase is performed.
• Alerting - Email notification is sent to subscription admin whenever a critical operation like Delete Backup data is performed, ensuring administrators are aware of operations affecting access or recoverability.
• Recovery - Deleted backup data is retained for additional 14 days from the date of delete. This ensures recoverability of the data within given time period so there is no data loss even if an attack happens. Also, the number of minimum recovery points are maintained to guard against corrupt data.

Security Features

There are three primary security features. Once enabled, you get these Security Features for all the Azure Recovery Services Agent (MARS) machines, Azure Backup Servers and DPM servers registered with the vault.

• Retention of deleted backup data. As a security measure, Azure Backup retains deleted backup data for additional 14 days (by default) and does not delete it immediately if Stop backup with delete backup data operation is performed. Microsoft a minimum retention range check based on the type of backup (daily, weekly, monthly or yearly), ranging from a minimum of one day for daily, up to one-year retention for deleted yearly backups.
• Alerts and notifications. Whenever some critical operations are performed, the subscription admin will be sent an email notification with details about the operation. However, you can configure additional IDs in the Azure portal.
• Multiple layers of security. As part of adding an extra layer of authentication for critical operations, you would be prompted to enter Security PIN when performing Stop Protection with Delete data and Change Passphrase operations.

Note: These features are enabled by default for newly created recovery services vaults. Enabling this setting is a one-time action and you cannot disable these features after enabling them.

Security Feature Prerequisites & Limitations

Before you enable these features, there are some prerequisites and limitations to be aware of:

• Agent & server versions. These security features only support the following agents and server minimum version MABS agent (2.0.9052), Azure Backup Server (update 1), and DPM 2012 R2 (UR12) or DPM 2016 (UR2).
• Vault support. Only recovery services vaults are supported. These features are not available for backup vaults.
• IaaS VM backup. These security features are not yet available for IaaS VM backup. Enabling these features on IaaS backups will have no effect.

STEP-BY-STEP: The steps to enable these features are simple and already well-documented on the Microsoft website in "Security features for protecting hybrid backups using Azure Backup" at http://bit.ly/2lqz2Ft.

Protecting Shielded VMs

Shielded VMs in Windows Server 2016 help protect sensitive VMs from inspection, tampering, and data theft (exfiltration) by malware and malicious administrators. DPM 2016 backups retain the protections provided by shielded VMs to ensure they can be recovered seamlessly and securely.

Note: Currently, neither Azure Backup nor MABS support shielded VMs yet.

Trusted Platform Modules (TPM) are a chip in the motherboard of computers that help integrate cryptographic keys. These keys are used by BitLocker to protect the computer, even if it is stolen. Virtual TPM (vTPM) is a feature in Windows Server 2016, that allows you to use BitLocker and a virtual TPM chip to encrypt a VM with Bitlocker, protecting the VM. These VMs, called Shielded VMs, can only be run on healthy and approved hosts in the fabric.

DPM 2016 supports backup and recovery of Shielded VMs that have their VHDs/VHDXs protected with a virtual TPM.

Note: Item Level Recovery (ILR) and Alternate Location Recovery (ALR) to a location outside the guarded fabric is not available for this scenario.

Recovering Individual Files and Folders

Recovery of individual files and folders is a new feature in Azure Backup, released in Preview in early 2017. Azure Backup will do an online backup by default for the first backup, but some customers might have a large amount of data (terabytes typically) that they want to ship by secure dis. instead, which is possible via the offline backup workflow in Azure Backup. Once the first backup is completed, Azure Backup switches to a "changes only" backup.

A backup schedule is created when you complete the wizard, but a backup is not performed until the first scheduled time. You can wait for the first backup to take place, or you can trigger a manual backup by clicking Back Up Now in the Actions pane of the Azure Backup console.

Instant File Recovery

The compelling value proposition of Instant File Recovery is how you restore individual files and folders using the VM-level backup, eliminating the need to backup files with the MARS agent, which doubles your effort and expense. With Instant File Recovery, you recover files and folders through a recovery point mounted using iSCSI, which points to your VM backup.

Note: You will still need to install the January 2017 (version 2.0.9062.0) or later of the MARS agent to use Instant File Recovery. However, you do not need to create another backup beyond that created by the VM-level backup of your Azure VM.

To recover a file using the Instant File Recovery feature, perform the following steps:

1. Select your VM level backup in the Azure portal, by browsing to < Recovery vault> > Backup Items > Virtual Machine > <VM backup item>.
2. Next, click the File Recovery (Preview) menu item.

FIGURE 3. INSTANT FILE RECOVERY INTERFACE

1. Click the Download Executable button to download the script that will mount the recovery point. Be sure to select Save, not Run!
2. Once the executable download completes, you will need to save, right click and select Properties, then click the Unblock button present on all files downloaded from the Internet.
3. Then, run the executable as Administrator. If it runs successfully, you will see a result similar to that shown in Figure 4.

FIGURE 4. INSTANT FILE RECOVERY SCRIPT RESULT

IMPORTANT: if you do not save the File Recovery script and click the 'Unblock' button in the script, the script will return an error when you attempt to run it.

1. Basically, the on-premises computer (physical or virtual) mounts a recovery point in the recovery services vault in Azure, which appears as a usable volume in File Manager.

At this point, you can browse through the file structure on the mounted drive, open files and folders to verify the content before you restore the content on the mounted local drive ('E:\Local Disk' in this example, as shown in Figure 4). You simply copy the file from the mounted recovery point and paste to an alternate location, just as you would with Windows Previous Versions.

1. When you are done, you simply click the Unmount Disks button shown in Figure 3 or let the mount point expire and auto-unmount in 12 hours.

Note: At the time this chapter was written, this feature is only available in Azure Backup. It is not yet available with DPM or MABS.

Alerting and Monitoring on Backups

If you are an existing Azure backup customer using recovery services vault, update to the latest azure backup agen. to use this feature. If you have configured email notifications before enrolling, turn off email notifications, enroll the subscription, and then configure notifications.

A short 5-minute video on alerting and monitoring capability for Azure Backup is available on the Microsoft website at http://bit.ly/2lTTa1P.

If you want to integrate the alerts into OMS, you could do this via the HTTP Data Collector API. For an example of the Data Collector API, see the chapter on Custom Solutions later in this book or visit "Send data to Log Analytics with the HTTP Data Collector API" on the Microsoft website at http://bit.ly/2lnHhy0.

VMware Backup with MABS

In late 2016, Microsoft announced MABS support for VMware VM backup to disk and to cloud for an offsite copy or long-term retention.

• Agentless Backup. Azure Backup Server uses VMware's VADP API to protect VMware VMs remotely without installing agents on vCenter or ESXi servers, freeing administrators from the effort and hassle of managing agents for VMware VM backup.
• Discoverability and Auto-Protection. You can now discover and protect VMware VMs residing on external storage targets, such as NFS and cluster storage. Since VMs are discovered and protected at folder level automatically, managing large VMware environments much easier. Any future VMs added to a protected folder are backed up automatically.
• Integrated Hybrid backup. You can back implement both disk-to-disk onpremises for faster operational recovery, coupled with a disk-to-cloud copy for long term retention.

Note: You must download and install Update 1 to leverage the VMware backup feature, which is available on the Microsoft website at http://bit.ly/2lZLCL2.

STEP-BY-STEP: Step-by-step instructions for configuring the new VMware protection feature are available in "Four simple steps to backup VMware VMs with MABS" on the Microsoft website at http://bit.ly/2mkp9cd.

Azure Site Recovery

A key piece of any business continuity plan is a solid disaster recovery procedure. Azure provides a robust disaster recovery engine via Azure Site Recovery, which is capable of orchestrating seamless failover between your data centers. What's more, Azure Site Recovery also provides easy-to-use tools for testing your disaster recovery plan, ensuring that in the event of a disaster, your business continuity plan is already well tested, and your plan executes as expected.

Overview

With Windows Server 2012, Microsoft introduced Hyper-V Replica. This technology is built into the Hyper-V hypervisor role, enabling encrypted replication of the VM data and configuration from one Hyper-V host to another. Replication occurs at intervals of 30 seconds, 5 minutes, 15 minutes or 30 minutes. This helps to ensure that 'standby' virtual machines are always recent copies of mission-critical servers, shortening the recovery time in the event of a disaster. Replica VMs can be configured to utilize the same IP addresses as the source, or alternatively, use a different IP address space. Additionally, recovery points can be created, enabling recovery to an earlier point in the day (up to the last 24 hours). This functionality is all built-in free of charge in Windows Server 2012 and later.

Of course, in the event of a disaster, someone needs to make the decision to switch over to the replicas and initiate the process. Often, applications must be failed over in a specific order to account for dependencies (e.g. – SQL services require Active Directory to authenticate service and user accounts), opening up the possibility of human error in the failover process. In the event of a disaster, the human factor can become a bottleneck to a speedy recovery.

Microsoft Azure's Disaster Recovery as a Service (DRaaS) solution, Azure Site Recovery (ASR) drastically simplifies the failover process, enabling administrators to create groups of VMs that failover together, enabling single-click orchestrated failover in the event of a data center going offline. ASR leverages System Center Virtual Machine Manager (VMM) & Hyper-V Replica, by monitoring the VMM servers, and replicating configurations, snapshots, and data from one location to the destination. ASR can replicate the onpremises data center VMs from Hyper-V to Azure IaaS, enabling cost savings by eliminating the need for a second physical data center. This makes ASR a comprehensive, automated, and highly capable disaster recovery tool. Unlike the competitive solutions for ASR, you only pay for IaaS in the case of an actual failover while paying the storage cost only during idle times.

As of today, ASR has a few unsupported scenarios you should be aware of

• Unified Extensible Firmware Interface (UEFI)/Extensible Firmware Interface
• (EFI) boot is not supported.
• BitLocker encrypted volumes are not supported.
• Clustered servers are also not supported.
• Volumes larger than 1023 MB cannot be protected.

Let's take a look at the supported scenarios that ASR provide for creating a BCP solution.

1. Hyper-V to Azure (no VMM)

ASR acts as the replication broker in this scenario. This is ideal for SMEs with 1 – 5 individual Hyper-V hosts that are not managed by VMM.

1. Hyper-V to Azure (with VMM)

This is for organizations with a larger number of Hyper-V hosts managed by either single or multiple VMM servers. ASR pulls the configuration data from VMM servers and you can leverage ASR recovery plans to automate an orchestrated recovery schedule.

1. VMware to Azure

This is a more popular scenario as there are many organizations that have invested in VMware for their datacenter workloads and looking for a cloud-based cost effective BCP solution rather than investing for hardware and VMware Site Recovery.

1. Physical servers to Azure

Similar to VMWare scenario. A physical site can be EC2 instances hosted in Amazon Web Services as well thereby providing a competitive advantage for your BCP solution.

1. Hyper-V to a secondary Hyper-V site (with VMM)

If you want to leverage on-premises Hyper-V Replica technology with VMM while letting ASR handle the orchestrated recovery for your critical workloads, then this is the solution for you.

1. Hyper-V to a secondary Hyper-V site with SAN replication (with VMM) Leverages SAN replication technology provided by SAN vendors to provide near real-time replication. Following is the list of SAN vendors and respective SAN products that support the ASR recovery scenarios.

TABLE 5. SAN SUPPORT FOR ASR RECOVERY SCENARIOS

1. VMware VMs to a secondary VMWare site

Traditionally you would use VMWare Site Recovery Manager to achieve this functionality. InMage Scout included in Azure Site Recovery provides makes this scenario possible thereby saving you the cost of SRM licensing if you already an Azure customer.

1. Physical servers to a secondary site

This scenario utilizes the InMage Scout technology, a company which Microsoft acquired in 2014. Again, you can use this to configure a BCP solution between two AWS datacenter locations.

STEP-BY-STEP: Step-by-step guidance on configuring ASR, as well as a list of FAQs, is available on the Microsoft site at https://azure.microsoft.com/en-us/documentation/services/siterecovery/. or get the PDF version at https://docs.microsoft.com/pdfstore/en-us/Azure.azuredocuments/live/site-recovery.pdf.

Between two Hyper-V Sites managed by SCVMM

The simplest and easiest implementation of ASR would be to use Hyper-V Replica. Using the native, out of box functionality in Windows Server requires the least amount of effort to configure. At a high level, the configuration process is as follows:

1. Create an Azure Site Recovery Vault. The Site Recovery Vault is essentially a grouping of assets and logical entities relating to your Site Recovery solution. It includes things like recovery plans, which define automated recovery actions, and how/which VMs will be failed over when the plan is executed.
2. Install the Azure Site Recovery Provider on your VMM servers. The Site Recovery Provider is essentially a plugin for VMM, enabling the VMM installations in each data center to plug into ASR. The provider is used to synchronize information about the Hyper-V servers, VMM clouds, snapshots, and VMs to Azure.
3. Install the Microsoft Azure Recovery Services Agent on your Hyper-V hosts. The Recovery Services serves to replicate data from Hyper-V to Azure. You can specify specific proxy connections for the agent to use if you do not want it to utilize the default internet settings on your Hyper-V host. The agent can be pushed out through standard methods, such as Group Policy or System Center Configuration Manager (SCCM).
4. Configure protection settings for VMM clouds in the VMM console. You can specify which VMM clouds you want to show up in Azure Site Recovery Manager, minimizing the amount of visual noise in the Azure console. You can also define how the initial replications are performed, whether it be offline or online. Settings, such as the frequency of replication and number of recovery points in the last 24 hours can also be set, as well as the target cloud in the disaster recovery data center. Data compression can be turned on in this step as well, enabling smaller amounts of data to be transferred over the WAN, at the expense of additional CPU utilization on the source Hyper-V host. The authentication mechanism and port can also be chosen, enabling you to define more granular throttling policies at the network level. This ensures that WAN bandwidth is not completely consumed during replications.
5. Configure network and storage mappings. Network mappings allow you to define which VM Network a VM will be joined to when it fails over to the replica in the DR location, ensuring that it receives appropriate connectivity during failover. Storage mappings allow you to define storage classification mappings, ensuring that appropriate disk subsystems are available on the replicated VMs.
6. Enable protection for virtual machines. In the Azure Site Recovery Manager, you turn on protection for VMs on a VM by VM basis, ensuring that only necessary VMs are replicated from one data center to another.
7. Configure recovery plans. The recovery plan defines how VMs will be failed over, which VMs will be failed over, and in which order they will failover. Scripts and manual actions can be added to the plan, enabling automation of failover actions, as well as a pause for necessary manual actions. The manual actions must be marked as complete before the recovery plan continues with further actions.

How does failover work for Hyper-V VMs?

Below diagram provides a better understanding of how failover works in ASR for Hyper-V workloads. Some of the important steps are briefly described to provide an insight into what's happening under the hood in ASR.

FIGURE 5. PROTECTION WORKFLOW FOR HYPER-V VMS

Enable protection: When you enable protection for VMs ASR will create and trigger an Enable Protectionjob which validates that the VM complies with prerequisites. At this point, the Hyper-V host will initialize a full VM replication to the ASR vault.

Initial replication: During this process, a snapshot of the VM is taken and VHDs are replicated one by one to Azure or to the secondary datacenter. One of the important facts to remember is that the duration to complete a full replication depends on the size of the VHDs, network bandwidth and the initial replication method you've chosen. Once the initial replication finishes the VM snapshot is deleted and the delta changes in the log are then synchronized and merged.

Finalize protection: This is the final step of enabling the protection where a Finalize protection job configures network and other post-replication settings for the VM. After this, you will be able to change the settings for replica VM in Azure (i.e. instance size) so that you will not be overconsuming your Azure resources.

Replication Issues:

• Replication failure: This happens when delta replication fails and a full replication. This means that the data is out of sync and to avoid a full replication resynchronization occurs. A resynchronization operation computes checksums of the source and target VMs and sends only the delta changes to minimize the amount of data transfer. Once resync finishes delta replications resume. Although by default resynchronization is scheduled to run automatically outside office hours, you can resynchronize a VM manually whenever you require.
• Replication error: If you are experience network communication issues there is a high chance for the replication schedule to be missed. ASR will retry to continue the next cycle. For non-recoverable errors, such as If an authentication or authorization error, or a replica VM in an invalid state there will be no retry but for recoverable errors such as network errors, or low disk space/memory retries occur with increasing intervals between retries. Planned/unplanned failovers: Keep in mind that failovers should be initiated only when a need arises and the type of a failover should match your BCP situation. For example, if your goal is to test your DR solution you should initiate a test failover, not an unplanned failover. In a planned failover source VMs are shut down and once replica VMs are created they're in a commit pending state. Unless you are utilizing SAN replication you should manually commit to complete the failover. Once you are through with a failover you can failback to the primary site where the reverse replication is automatic if your target site is Azure or otherwise you will have to manually trigger the reverse replication action.

For a complete reference on failover scenarios, you can refer the Azure Site Recovery documentation at https://azure.microsoft.com/en-us/documentation/articles/siterecovery-failover/.

VMware to Azure

In 2014, Microsoft acquired a company called InMage Systems. InMage offered a product that would replicate physical and VMware servers across the WAN between data centers. This acquisition led to integration and development of InMage functionality into the ASR feature, resulting in an updated ASR feature with support for disaster recovery of VMware VMs.

Key features of this offering are:

• Heterogeneous workload support for multiple Windows and Linux editions with replication to and recovery in Azure.
• Automated discovery of VMware vCenter Server managed VMs for replication to and recovery in Azure.
• Continuous data protection with software-based replication to provide nearzero Recovery Point Objectives (RPO).
• On-the-fly conversion of source VMware Virtual Machine Disk (VMDK) files to bootable target Azure Virtual Hard Disk (VHD) files, ensuring low Recovery Time Objectives (RTO).
• Multi-VM consistency using ASR Protection Groups to ensure that all tiers of an n-tier application replicate consistently and fail over at the same time.
• Failback to VMware infrastructure from Azure when on-premises data center returns to service post-disaster.
• Active-passive replication that does not require running target Azure VMs at the time of replication, unlike other competitive disaster recovery products, thereby reducing the Total Cost of Ownership (TCO).
• Single-Click Failovers with ASR Recovery Plans to provide end-to-end workload-aware disaster recovery and orchestration at low Recovery Time Objectives (RTO).
• Health monitoring for replication, failover, and failback, with events and email notifications.

Recently Microsoft has introduced an enhanced model for VMware/Physical to Azure scenario where the complication of the setup procedure has been much simplified. Previously you had to deploy Azure IaaS VMs to handle to incoming replication to an ASR vault but with this new model, VM data replicates directly to an Azure storage account.

Some of the notable additions in the enhanced deployment scenario are listed below.

• Recovery points: Support for crash-consistent and application-consistent recovery points for Windows and Linux environments, and supports both single VM and multi-VM consistent configurations.
• Test failover: Support for non-disruptive test failover to Azure, without impacting production or pausing replication.
• Unplanned failover: Support for unplanned failover to Azure with an enhanced option to shut down VMs automatically before failover.
• Failback: Integrated failback that replicates only delta changes back to the onpremises site.
• vSphere 6.0: Limited support for VMware vSphere 6.0 deployments.

STEP-BY-STEP: For step-by-step documentation on configuring VMware protection with ASR, see "Replicate VMware virtual machines and physical servers to Azure with Azure Site Recovery" on the Microsoft website at https://azure.microsoft.com/enus/documentation/articles/site-recovery-vmware-to-azure-classic.

ASR & ARM

Up to this point, all the scenarios that we've discussed on ASR are compatible with the Azure Service Management (ASM) model. Azure Resource Manager (ARM) model supports most of the services offered by Azure while continuously adding and improving existing services to the new fabric.

Currently, the support for ARM is limited to:

• VMware VMs or physical servers to Azure
• Hyper-V VMs in VMM clouds to Azure
• Hyper-V VMs (without VMM) to Azure
• Hyper-V VMs in VMM clouds to a secondary site

This is achieved through ARM cmdlets for ASR and it is not an option in the new Azure portal. If you are planning to utilize ASR for the rest of the scenarios described in this chapter, you should keep in mind that you still need to leverage the ASM model.

STEP-BY-STEP: A step-by-step guidance on configuring ASR with ARM cmdlets is available at https://azure.microsoft.com/enus/documentation/articles/site-recovery-deploy-with-powershellresource-manager.

Backing Up SQL Workloads to Azure

Since SQL Server is one of the most common (and often most critical) workloads hosted in Azure, coverage of options for protecting SQL server and databases instances in Azure VMs is warranted. Aside from the Azure Backup Server and Azure Backup service, there are multiple ways you can leverage Azure as part of your SQL backup and recovery strategy, including:

• SQL Database Backup to Azure Blob Storage
• Automated SQL Backup in Azure VMs

Both of these options are described in detail in this section, including a step-by-step tutorial on how to configure SQL database backups directly to Azure Blob Storage. The latter is an easy-to-configure and economical option.

SQL Database Backup to Azure Blob Storage

You can actually perform backups of SQL databases directly to a blob in Azure storage, even without a service like Azure Backup. This option will work for SQL Server instances running in on-premises VMs, as well as SQL instances running in Azure VMs.

Benefits

You can back up your databases to Microsoft Azure without having to manage devices and manage storage capacity on those devices. You can back up the databases to Microsoft Azure based on the activity of your databases. You can take a SQL log backup only when needed, such as when space used in database logs is running low. There are several benefits to this approach, including:

• Off-site, highly redundant storage to meet compliance regulations and industry standards.
• Lower management and operating costs, no hardware management, and lowcost storage.
• More time to focus on other tasks and no need to spend time managing storage for backups.

Considerations

There are a few things to bear in mind as you prepare to leverage SQL backup to Azure:

• A backup file can be a maximum of 1 TB in size.
• Backup and restore times will vary based on the bandwidth and latency of your network connection.

To backup databases from versions of SQL Server older than SQL Server 2014, you must download and install the "Microsoft SQL Server Backup to Microsoft Azure Tool". This tool enables backup to Azure from SQL Server 2005, 2008 and 2008 R2 databases with encryption capabilities. You can download this tool at http://www.microsoft.com/enus/download/details.aspx?id=40740.

Step-by-Step: Performing a SQL Database Backup to Azure

In order to configure SQL database backups to Azure blobs, there are few things you that will need in Azure Storage:

• Storage Account: The storage account is the starting point for all storage services. To access the Windows Azure Blob Storage service, begin by creating an Azure storage account. The storage account name and its access key properties are required to authenticate to the Azure Blob Storage service and its components.
• Container: A container provides a grouping of a set of Blobs, and can store an unlimited number of Blobs. To write a SQL Server backup to the Azure Blob service, you must have at least the root container created.
• URL: A URL specifies a Uniform Resource Identifier (URI) to a unique backup file. The URL is used to provide the location and name of the SQL Server backup file. In this implementation, the only valid URL is one that points to a page Blob in an Azure storage account. The URL must point to an actual Blob, not just a container. If the Blob does not exist, it is created. If an existing Blob is specified, the backup fails, unless the "WITH FORMAT" option is specified.
• Blob: A file of any type and size. There are two types of blobs that can be stored in the Azure Blob storage service: block and page blobs. SQL Server backup uses page blobs as the blob type. Blobs are addressable using the following URL format: https://<storage account>.blob.core.windows.net/<container>/<blob>.

IMPORTANT: If you choose to copy and upload a backup file to the Microsoft Azure Blob storage service, use page blob as your storage option. Restores from Block Blobs are not supported. RESTORE from a block blob fails with an error.

• Credential: A SQL Server credential is an object that is used to store authentication information required to connect to a resource outside of SQL Server. SQL Server backup and restore processes use the credential to authenticate to the Azure Blob storage service. The Credential stores the name of the storage account and the storage account access key values.

At a high level, following are the steps for creating SQL workload backups:

• Create Azure Storage Account
• Create Azure Storage Container
• Create Credential
• Backup Using the Backup Task (in SSMS)
• Backup Using T-SQL BACKUP DATABASE Command

Once you have a created a backup, you may be interested in how to recover a database using a backup hosted in Azure storage. The restore process will be covered in the "Restoring Data from an Azure Blob" section later in this chapter.

Create Azure Storage Account:

If you are not already logged into the Azure Management Portal, open a supported web browser and browse to https://manage.windowsazure.com/, then sign in using your credentials.

1. Click Browse & Search for Storage Accounts from the navigation pane on the left, as shown in Figure 6. Here we are creating a v2 storage account, not a classic storage account.

FIGURE 6. STORAGE BLADE IN THE AZURE MANAGEMENT PORTAL

1. Click +Add in the Storage Blade

FIGURE 7. STORAGE CONTAINER QUICK CREATE

1. Provide a name for the new storage account, select the storage account type and select an existing or create a new resource group for the storage account as in Figure 8.

FIGURE 8. STORAGE ACCOUNT CREATION IN NEW AZURE PORTAL

1. In Location, select the geographic region for the storage account.
2. Click Create to create the new storage account.

Create Azure Storage Container

To create a storage container in Azure, perform the following steps:

1. In the Azure Management Portal, select the storage account you previously created, then select the Blobs Tile, as shown in Figure 9.

FIGURE 9. STORAGE BLOBS TILE

1. Click +Container button to open the New container dialogue.

FIGURE 10.BLOB SERVICE DIALOG BOX

1. Enter a unique value in the Name field, and set a value for Access by selecting Private and click Create as shown in Figure 11 below.

FIGURE 11. NEW CONTAINER DIALOG BOX

Create Credential

To create a credential for accessing and writing backups to blobs in Azure storage, perform the following steps:

• Launch SQL Server Management Studio (SSMS).
• Expand the Security node.
• Right click the Credentials node and select New Credential from the context menu, as shown in Figure 12. This opens a New Credential window.

FIGURE 12. NEW CREDENTIAL MENU IN SSMS

• In the New Credential window (shown in Figure 12), specify the following values for ease of use:
  • Credential Name – Use the name of the storage container
  • Identity – Use the name of the storage account
  • Password – The access key from the storage container. You can find this value by selecting the storage container in the Azure portal, and at the Settings Blade, selecting Access Keys. Copy the primary access key(KEY1), as shown in Figure 13.

FIGURE 13. NEW CREDENTIAL DIALOGUE

• When you have filled in the values above, click OK.

FIGURE 14. MANAGE ACCESS KEYS BLADE IN THE AZURE PORTAL

You are now ready to perform a SQL backup to Azure storage.

Backup Using the Backup Task in SSMS

The Backup task in SQL Server Management Studio has been enhanced to include URLs as one of the destination options, and other supporting objects required to backup to Windows Azure storage, such as the SQL Credential.

To back up a SQL database to Azure storage, perform the following steps:

1. Start SQL Server Management Studio and connect to the SQL Server instance. Select a database you want to backup, right click on Tasks, and select Backup..., as shown in Figure 15. This opens the Backup Database dialog box.

FIGURE 15. SQL BACKUP WIZARD IN SSMS

1. On the general page, select the URL option to create a backup to Azure storage, as shown in Figure 16. When you select this option, you see other options enabled on this page:
   1. File Name: Name of the backup file.
   2. SQL Credential: You can either specify an existing SQL Server Credential or create a new one by clicking on the Create next to the SQL Credential box.

FIGURE 16. BACKUP DATABASE DIALOGUE

NOTE: The dialog that opens when you click Create requires a management certificate or the publishing profile for the subscription. SQL Server currently supports publishing profile version 2.0. It is easier to simply create the credential as documented in the previous step.

1. Azure storage container: The name of the Windows Azure storage container to store the backup files.
2. URL prefix: This is built automatically using the information specified in the fields described in the previous steps. If you do edit this value manually, make sure it matches with the other information you provided previously. For example, if you modify the storage URL, make sure the SQL Credential is set to authenticate to the same storage account.

Backup Using T-SQL BACKUP DATABASE Command

To back up a database to Azure storage using a T-SQL query, perform the following steps:

• In SQL Server Management Studio, right-click the database you want to backup and select New Query.
• Enter the following T-SQL command into the query window, replacing the database name, URL, and Credential with the values from your environment. Specify a file name on the end of the URL, which will be created at runtime. There are two examples below,

Backup (default compression, which is no compression)

BACKUP DATABASE Master

TO URL =

'https://insidemscloud.blob.core.windows.net/insidemscloudsql/MasterNoCompress.bak'

WITH CREDENTIAL = 'insidemscloud-sql' ,STATS = 1

To turn compression on, simply add the COMPRESSION option as shown below

BACKUP DATABASE Master

TO URL =

'https://insidemscloud.blob.core.windows.net/insidemscloud-

sql/MasterCompress.bak'

WITH CREDENTIAL = 'insidemscloud-sql'

,COMPRESSION

,STATS = 1

When finished, check the target Azure storage container to verify the backup is present. In Figure 17, you will notice that the backup file created with COMPRESSION specified is much smaller than when compression is not specified.

FIGURE 17. SQL BACKUP FILES IN AZURE STORAGE

TIP: Backing up with the COMPRESSION option means lower storage usage and thus, lower costs to store your SQL database in Azure. Notice the size difference with and without compression shown in Figure 17.

Now that you have created a database backup, you can attempt to restore a backup from Azure storage.

Restoring from Microsoft Azure Storage

If you are restoring a database, URL is included as the device to restore from. The following steps describe the changes in the Restore task to allow restoring from Microsoft Azure storage:

1. Right-click on the database you want to restore and select Tasks  Restore  Database, as shown in Figure 18.

FIGURE 18. LAUNCHING THE RESTORE DATABASE DIALOGUE

1. When you select Devices in the General page of the Restore task in SQL Server Management Studio, this takes you to the Select backup devices dialog box, which includes URL as a backup media type.
2. Select URL and click Add. This opens the Connect to Azure storage dialog. Specify the SQL Credential information to authenticate to Azure storage, as shown in Figure 19.

FIGURE 19. CONNECT TO WINDOWS AZURE STORAGE DIALOGUE

1. SQL Server then connects to Azure storage using the SQL Credential information you provided and opens the Locate Backup File in Windows Azure dialog. The backup files residing in the storage are displayed on this page. Select the file you want to use to restore and click OK.

   This takes you back to the Select Backup Devices dialog, and Clicking OK on this dialog takes you back to the main Restore dialog (shown in Figure 20) where you will be able complete the restore.

FIGURE 20. RESTORE DATABASE DIALOGUE

1. You can use the Script menu to create a T-SQL restore script and save to file, clipboard or open in a new query editor window, as shown in Figure 21. You can also select the Agent Job option, which will bring your selections in the Restore Database wizard into the Schedule Job interface.

FIGURE 21. RESTORE DATABASE DIALOGUE

As you can see, backing up and recovering SQL databases from backups stored in Azure is a straightforward process.

Automated SQL Backup in Azure VMs

A key piece of any business continuity plan is a solid disaster recovery procedure. Azure provides a storage platform that enables organizations to store their SQL backup offsite.

The following products are compatible with the SQL Server IaaS Agent features.

Automated Backup:

• Windows Server 2012
• Windows Server 2012 R2
• SQL Server 2014 Standard
• SQL Server 2014 Enterprise

Automated Patching:

• Windows Server 2012
• Windows Server 2012 R2
• SQL Server 2012
• SQL Server 2014

NOTE: You can automate patching of SQL 2012 and 2014 VMs, but the automated backup feature is only available for SQL 2014.

Automated Backup automatically configures Managed Backup to Microsoft Azure for all existing and new databases on an Azure VM running SQL Server 2014 Standard or Enterprise. This enables you to configure regular database backups that utilize durable Azure blob storage. The actual configuration steps vary depending on whether you use the Azure Portal (pictured in Figure 22) or Azure Windows PowerShell commands.

Azure Service Management (ASM) Option

If you want to protect classic Azure VMs following will help to configure automated SQL server backup.

FIGURE 22. AUTOMATED SQL BACKUP OPTION IN AZURE CLASSIC VMS

To enable this feature on a VM that is already deployed, you will have to use Azure PowerShell to complete the configuration. A sample script is included below. Be sure update the values in brackets <> with values applicable to your environment.

It could take several minutes to install and configure the SQL Server IaaS Agent. View the status of the VM in the Azure Management Portal. It should indicate that it is installing extensions. The extensions area should also report that the

Microsoft.SqlServer.Management.SqlIaaSAgent is being enabled. In PowerShell, you can test that the extension has completely installed and configured by using the following command:

(Get-AzureVM -ServiceName <vmservicename> | ` Get-AzureVMSqlServerExtension).AutoBackupSettings

To disable automatic backup, run the same script without the -Enable parameter to the New-AzureVMSqlServerAutoBackupConfig. As with installation, it can take several minutes to disable Automated Backup.

Download the Code

You can download the full script from GitHub at https://github.com/insidemscloud/OMSBookV2, in the \Chapter 15 directory. The file name is SQLAutoBackupASM.ps1.

Azure Resource Manager Option

FIGURE 23. AUTOMATED SQL BACKUP OPTION IN V2 AZURE IAAS VMS

Like in previous ASM option you can use below PowerShell snippet to enable automated SQL backup for an existing ARM VM.

As it takes several minutes to configure the SQL Server IaaS Agent when you enable Automated Backup for the first time, the Azure portal might not show that Automated Backup is configured. Once the agent is installed and configured these changes will be reflected in the portal.

To disable automatic backup, run the same script without the -Enable parameter to the AzureRM.Compute\New-AzureVMSqlServerAutoBackupConfig command. One thing to keep in mind is that removing the SQL Server IaaS Agent does not remove the previously configured Automated Backup settings and therefore you need to disable Automated Backup before disabling or uninstalling the SQL Server IaaS Agent.

Download the Code

You can download the full script from GitHub at https://github.com/insidemscloud/OMSBookV2, in the \Chapter 15 directory. The file name is SQLAutoBackupARM.ps1.

3^rd Party Azure-Integrated Backup

A popular independent software vendor (ISV) that provides Azure-integrated backup solutions is Veeam Software. Their core enterprise backup solution is called Veeam Backup & Replication.

Veeam Backup & Replication is a solution specifically built for virtual environments. It operates at the virtualization layer and uses an image-based approach for VM backup. To retrieve VM data, no agent software needs to be installed inside the guest OS. Instead, Veeam Backup & Replication leverages VSS snapshot capabilities. When a new backup session starts, a VSS snapshot is taken to create a cohesive point-in-time copy of a VM including its configuration, OS, applications, associated data, system state and so on. Veeam Backup & Replication uses this point-in-time copy to retrieve VM data. Imagebased backups can be used for different types of recovery, including Instant VM Recovery, full VM recovery, VM file recovery and file-level recovery.

The latest version of Veeam Backup and Replication (v9) supports the following operating systems, file systems, and applications.

• vSphere 4.1, 5.x, 6.0
• ESX(i) 4.1, ESXi 5.x, ESXi 6.0
• Hyper-V on Windows Server 2008 R2 SP1, 2012, 2012 R2, Microsoft Hyper-V Server 2008 R2 SP1, 2012, 2012 R2
• All operating systems supported by above Hyper-V and VMware editions
• Any application
• Any file system

You can protect both VMware and Hyper-V hosts directly. Having vCenter/vCloud Director or SCVMM deployed is optional.

When using Microsoft Azure for offsite backups with Veeam, there are three implementation options.

• Veeam Integration with StorSimple
• Veeam Cloud Connect for Service Providers
• Veeam Cloud Connect for Enterprise

Each option is described briefly in the sections that follow.

Veeam Integration with StorSimple

The StorSimple hybrid cloud storage solution adds dynamic storage tiering across SSD, SAS and Microsoft Azure to ensure data growth requirements are always met. StorSimple uses Azure as an extension of its on-premises storage arrays and automatically tiers data across on-premises storage and cloud storage.

StorSimple, make data protection and archiving to Azure easy and efficient. To Veeam, StorSimple looks like any another connected, on-premises data repository. However, StorSimple is more than just storage—it automatically manages the movement of data to and from Azure for efficient availability.

Veeam Backup & Replication™ provides agentless image-level backup to help meet stringent RPOs and RTOs while allowing more recovery options than you ever thought possible:

• Recovery of a failed VM in as little as two minutes
• Near-continuous data protection with built-in replication
• Fast, agentless item recovery and e-discovery for Microsoft Exchange, SharePoint and Active Directory, along with transaction-level recovery of SQL databases
• Automatic recoverability testing of every backup and every replica, every time

Veeam and StorSimple work in unison to mitigate the cost and management of data growth while providing secure backup and recovery. Veeam ensures that backups are initially stored on a traditional primary storage for short-term recovery, and depending on your availability needs, Veeam archives older versions of backups to StorSimple for long-term compliance. StorSimple will, in turn, ensure that backups are moved into Azure via cloud snapshot.

FIGURE 24. VEEAM BACKUP & REPLICATION COUPLED WITH STORSIMPLE

Veeam Cloud Connect for Service Providers

Veeam Cloud Connect^TM for Service Providers extends the functionality of Veeam Backup & Replication, enabling service providers to provide storage and recovery of backup data in Microsoft Azure. The Cloud Connect solution architecture is very simple, enabling service providers to provide customers (tenants) a hosted backup repository in Microsoft Azure. The solution architecture is quite simple, consisting of the following roles:

• Cloud Gateway - The Cloud Gateway is a network service running on a Windows server that resides on the service provider side and acts as a communication point in the cloud. It routes commands and traffic between the service provider, tenants, and the cloud repository.
• WAN Accelerator (optional) - WAN accelerators are optional components in the Veeam Cloud Connect infrastructure. Tenants may use WAN accelerators for Backup Copy jobs targeted at the cloud repository. WAN accelerators deployed in the cloud run the same services and perform the same role as WAN accelerators in an on-premises backup infrastructure. When configuring Veeam Backup Copy jobs, tenants can choose to exchange data over a direct channel or communicate with the cloud repository via a pair of WAN accelerators. To pass VM data via WAN accelerators, the service provider and tenants must each configure WAN accelerator, with the source WAN accelerator located on tenant side (in the tenant data center), the target WAN accelerator is configured on the service provider side.
• Tenant Veeam Backup Server - To connect to the cloud and use the cloud repository service provided by the service provider, tenants utilize Veeam backup servers deployed on their side.

FIGURE 25. VEEAM CLOUD CONNECT – POC ARCHITECTURE

Expanding the capacity of a single VM setup is easy to do by leveraging the distributed model of Veeam Backup & Replication, along with the rapid resource provisioning capabilities in Azure. The diagram below illustrates a distributed model.

FIGURE 26. VEEAM CLOUD CONNECT – PRODUCTION ARCHITECTURE

For systems integrators trying to build a successful business in the Microsoft cloud, Veeam Cloud Connect offers the ability to create a recurring revenue stream.

As a Veeam Cloud Connect Service Provider, you deploy the appliance from the Azure Marketplace, where you will find the Veeam Cloud Connect VM offering. If your company is not yet enrolled in the Veeam Cloud Provider Program, you can click the link provided in the Azure Marketplace offering and receive a 30-day trial.

FIGURE 27. VEEAM CLOUD CONNECT IN THE AZURE MARKETPLACE

You will find multiple resources on the Veeam website to get familiarized yourself with the solution, including the following whitepapers, which cover everything from reference architecture to comprehensive hands-on deployment guidance. Solution Brief:

• Veeam, StorSimple, and Microsoft Azure https://www.veeam.com/wp-veeam-storsimple-microsoft-azure.htm.
• Veeam Backup & Replication v8: Cloud Connect Reference Architecture http://www.veeam.com/wp-cloud-connect-reference-architecture-veeam-backupreplication-v8.htm.
• Veeam Cloud Connect: Manual configuration guide for Microsoft Azure http://www.veeam.com/wp-build-services-business-veeam-microsoft-azure.htm.
• Veeam Cloud Connect: Pre-configured VM deployment from the Microsoft Azure Marketplace http://www.veeam.com/wp-build-services-business-veeam-microsoft-azuremarketplace.htm.

These resources and a 30-day trial license make getting up to speed on how Veeam can help you to design your cloud availability strategy a manageable task.

Veeam Cloud Connect for Enterprise

Veeam Cloud Connect^TM for Enterprise, a new offering from Veeam, is a Cloud Connect option for customers who would prefer to manage their own hybrid disaster recovery strategy. You will find the Veeam Cloud for Enterprise offering in the Azure Marketplace as well. The VM is basically the same as the Service Provider edition and the difference is the license that enables the Enterprise edition.

Summary

Microsoft offers a number of workload protection options in Azure, enabling organizations to ensure their data is protected in the event of a disaster, even if they do not have a secondary data center. With the OMS Protection and Recovery offering, which includes the Azure Backup service, Microsoft has enabled a comprehensive, cloud-based offsite backup solution. Azure backup vaults provide secure, encrypted backup targets for customers of all sizes. Regardless of the fact that an organization has a more complex backup and recovery configurations utilizing System Center Data Protection Manager, or whether they have a simpler, more basic need for offsite backup, Azure Backup enables offsite backup for everyone. The Instant File Recovery feature adds tremendous value in reducing the need to deploy the MARS agent to facilitate recovery of individual files.

With Azure Site Recovery, Microsoft has enabled cloud-based disaster recovery orchestration. Perhaps one of the simplest, most easy-to-use implementations of disaster recovery solutions ever, Azure Site Recovery enables effective disaster recovery for organizations of all sizes. In Azure Site Recovery, disaster recovery plans can easily be tested, ensuring business continuity in the event of an actual disaster.

With multiple protection options for Microsoft SQL Server, organizations have greater flexibility in planning and implementing high availability and disaster recovery strategies for one of the most common (and often, most critical) workloads in a variety of scenarios.

For partners and customers looking to leverage capabilities of Azure as part of a hybrid disaster recovery strategy for heterogeneous environments, Veeam offers options to suit a variety of needs.

---