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:
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:
We will start with a look at OMS integration with Azure Backup and ASR.
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:
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.
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 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 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.
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:
To help sort through your options, the two tables below outline the capabilities and limitations of four different protection options:
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.
Component | What is protected? | Where are backups stored? |
Azure Backup (MARS) agent |
|
|
System Center DPM |
|
|
Azure Backup Server |
|
|
Azure IaaS VM Backup |
|
|
TABLE 1. PROTECTION AND BACKUP STORAGE
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.
Component | Benefits | Limits |
Azure Backup (MARS) agent |
|
|
System Center DPM |
|
|
Azure Backup Server |
|
|
Azure IaaS VM Backup |
|
|
TABLE 2. BENEFITS AND LIMITATIONS
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 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
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:
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/
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.
Version | DPM installation | DPM 2016 | Protection and recovery |
System Center VMM | |||
VMM 2016, VMM 2012, SP1, R2 | Physical server Hyper-V VM | Y | All deployment scenarios: Database |
Client computers | |||
Windows 10 (64-bit and 32bit) | Physical server Hyper-V VM VMware VM | Y | Files Protected volumes must be NTFS. FAT and FAT32 are not supported. Volumes must be at least 1 GB. DPM uses Volume Shadow Copy Service (VSS) to take the data snapshot and the snapshot only works if the volume is at least 1 GB. |
Windows 8.1 (64-bit and 32bit) | Physical server Hyper-V VM | Y | Files Protected volumes must be NTFS. FAT and FAT32 are not supported. Volumes must be at least 1 GB. DPM uses Volume Shadow Copy Service (VSS) to take the data snapshot and the snapshot only works if the volume is at least 1 GB. |
Windows 8.1 (64-bit and 32bit) | Windows VM in VMWare (protects workloads running in Windows VM in VMWare) | Y | Files Protected volumes must be NTFS and at least 1 GB. |
Servers (32-bit and 64-bit) | |||
Windows Server 2016 | Azure VM (when workload is running as Azure VM) Windows VM in VMWare (protects workloads running in Windows VM in VMWare) Physical server On-premises Hyper-V VM | Y Not Nano server | Volume, share, folder, file, system state/bare metal), deduped volumes |
Windows Server 2012 R2 - Datacenter and Standard | Azure VM (when workload is running as Azure VM) | Y | Volume, share, folder, file DPM must be running on at least Windows Server 2012 R2 to protect Windows Server 2012 deduped volumes. |
Windows Server 2012 R2 - Datacenter and Standard | Windows VM in VMWare (protects workloads running in Windows VM in VMWare) | Y | Volume, share, folder, file, system state/bare metal) DPM must be running on Windows Server 2012 or 2012 R2 to protect Windows Server 2012 deduped volumes. |
Windows Server 2012/2012 with SP1 - Datacenter and Standard | Physical server On-premises Hyper-V VM | Y | Volume, share, folder, file, system state/bare metal DPM must be running on at least Windows Server 2012 R2 to protect Windows Server 2012 deduped volumes. |
Windows Server 2012/2012 with SP1 - Datacenter and Standard | Azure VM (when workload is running as Azure VM) | Y | Volume, share, folder, file DPM must be running on at least Windows Server 2012 R2 to protect Windows Server 2012 deduped volumes. |
Windows Server 2012/2012 with SP1 - Datacenter and Standard | Windows VM in VMWare (protects workloads running in Windows VM in VMWare) | Y | Volume, share, folder, file, system state/bare metal DPM must be running on at least Windows Server 2012 R2 to protect Windows Server 2012 deduped volumes. |
SQL Server | |||
SQL Server 2016 | Physical server On-premises Hyper-V VM Azure VM Windows VM in VMWare (protects workloads running in Windows VM in VMWare) | Y (UR2 Onwards) | All deployment scenarios: database |
SQL Server 2014 | Azure VM (when workload is running as Azure VM) | Y | All deployment scenarios: database |
SQL Server 2014 | Windows VM in VMWare (protects workloads running in Windows VM in VMWare) | Y | All deployment scenarios: database |
SQL Server 2012 with SP2 | Physical server On-premises Hyper-V VM | Y | All deployment scenarios: database |
SQL Server 2012 with SP2 | Azure VM (when workload is running as Azure VM) | Y | All deployment scenarios: database |
SQL Server 2012 with SP2 | Windows VM in VMWare (protects workloads running in Windows VM in VMWare) | Y | All deployment scenarios: database |
SQL Server 2012, SQL Server 2012 with SP1 | Physical server On-premises Hyper-V VM | Y | All deployment scenarios: database |
SQL Server 2012, SQL Server 2012 with SP1 | Azure VM (when workload is running as Azure VM) | Y | All deployment scenarios: database |
SQL Server 2012, SQL Server 2012 with SP1 | Windows VM in VMWare (protects workloads running in Windows VM in VMWare) | Y | All deployment scenarios: database |
Exchange | |||
Exchange 2016 | Physical server On-premises Hyper-V VM | Y | Protect (all deployment scenarios): Standalone Exchange server, database under a database availability group (DAG) Recover (all deployment scenarios): Mailbox, mailbox databases under a DAG |
Exchange 2016 | Windows VM in VMWare (protects workloads running in Windows VM in VMWare) | Y | Protect (all deployment scenarios): Standalone Exchange server, database under a database availability group (DAG) Recover (all deployment scenarios): Mailbox, mailbox databases under a DAG |
Exchange 2013 | Physical server On-premises Hyper-V VM | Y | Protect (all deployment scenarios): Standalone Exchange server, database under a database availability group (DAG) Recover (all deployment scenarios): Mailbox, mailbox databases under a DAG |
Exchange 2013 | Windows VM in VMWare (protects workloads running in Windows VM in VMWare) | Y | Protect (all deployment scenarios): Standalone Exchange server, database under a database availability group (DAG) Recover (all deployment scenarios): Mailbox, mailbox databases under a DAG |
SharePoint | |||
SharePoint 2016 | Physical server On-premises Hyper-V VM | Y (UR2 Onwards) | Protect (all deployment scenarios): Farm, frontend web server content Recover (all deployment scenarios): Farm, database, web application, file or list item, SharePoint search, front-end web server Note that protecting a SharePoint farm that's using the SQL Server 2012 AlwaysOn feature for the content databases is not supported. |
SharePoint 2013 | Physical server On-premises Hyper-V VM | Y | Protect (all deployment scenarios): Farm, frontend web server content Recover (all deployment scenarios): Farm, database, web application, file or list item, SharePoint search, front-end web server Note that protecting a SharePoint farm that's using the SQL Server 2012 AlwaysOn feature for the content databases is not supported. |
SharePoint 2013 | Azure VM (when workload is running as Azure VM) - DPM 2012 R2 Update Rollup 3 onwards | Y | Protect (all deployment scenarios): Farm, SharePoint search, front-end web server content Recover (all deployment scenarios): Farm, database, web application, file or list item, SharePoint search, front-end web server Note that protecting a SharePoint farm that's using the SQL Server 2012 AlwaysOn feature for the content databases is not supported. |
SharePoint 2013 | Windows VM in VMWare (protects workloads running in Windows VM in VMWare) | Y | Protect (all deployment scenarios): Farm, SharePoint search, front-end web server content Recover: Farm, database, web application, file or list item, SharePoint search, front-end web server Note that protecting a SharePoint farm that's using the SQL Server 2012 AlwaysOn feature for the content databases is not supported. |
Hyper-V host - DPM protection agent on Hyper-V host server, cluster, or VM | |||
Windows Server 2016 | Physical server On-premises Hyper-V VM | Y | Protect: Hyper-V computers, cluster shared volumes (CSVs) Recover: VM, Item-level recovery of files and folder, volumes, virtual hard drives |
Windows Server 2012 R2 Version- Datacenter and Standard | Physical server DPM installation On-premises Hyper-V VM | Y | Protect: Hyper-V computers, cluster shared volumes (CSVs) Protection and recovery Recover: VM, Item-level recovery of files and folder, volumes, virtual hard drives |
Windows Server 2012 - Datacenter and Standard | Physical server On-premises Hyper-V VM | Y | Protect: Hyper-V computers, cluster shared volumes (CSVs) Recover: VM, Item-level recovery of files and folder, volumes, virtual hard drives |
Linux | |||
Linux running as Hyper-V guest | On-premises Hyper-V VM | Y | Hyper-V must be running on Windows Server 2012 R2 or Windows Server 2016. Protect: Entire VM Recover: Entire VM |
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.
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:
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.
The high-level steps to configure Azure Backup to protect Azure VMs are:
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.
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.
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.
Deployment | Portal | Vault |
Classic | Classic | Backup |
Resource Manager | Azure | Recovery Services |
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/
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.
The high-level steps for backing up Azure IaaS v2 VMs are:
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.
The high-level steps for backing up Classic Azure IaaS VMs are:
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.
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
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.
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.
Before you enable these features, there are some prerequisites and limitations to be aware of:
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.
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.
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.
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:
FIGURE 3. INSTANT FILE RECOVERY INTERFACE
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.
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.
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.
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.
In late 2016, Microsoft announced MABS support for VMware VM backup to disk and to cloud for an offsite copy or 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.
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.
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
Let's take a look at the supported scenarios that ASR provide for creating a BCP solution.
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.
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.
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.
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.
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.
Supported array | Replication groups | Planned failover | Unplanned failover | Test failover | Reverse replication |
NetApp Clustered Data ONTAP 8.2 | Yes | Yes | Yes | Yes | Yes |
HP 3PAR | Yes | Yes | Yes | Yes | Yes |
EMC VMAX Series | Yes | Yes | Yes | Yes | Yes |
TABLE 5. SAN SUPPORT FOR ASR RECOVERY SCENARIOS
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.
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.
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:
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:
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/.
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:
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.
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.
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:
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.
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:
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.
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.
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:
There are a few things to bear in mind as you prepare to leverage SQL backup to Azure:
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.
In order to configure SQL database backups to Azure blobs, there are few things you that will need in Azure Storage:
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.
At a high level, following are the steps for creating SQL workload backups:
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.
FIGURE 6. STORAGE BLADE IN THE AZURE MANAGEMENT PORTAL
FIGURE 7. STORAGE CONTAINER QUICK CREATE
FIGURE 8. STORAGE ACCOUNT CREATION IN NEW AZURE PORTAL
To create a storage container in Azure, perform the following steps:
FIGURE 9. STORAGE BLOBS TILE
FIGURE 10.BLOB SERVICE DIALOG BOX
FIGURE 11. NEW CONTAINER DIALOG BOX
To create a credential for accessing and writing backups to blobs in Azure storage, perform the following steps:
FIGURE 12. NEW CREDENTIAL MENU IN SSMS
FIGURE 13. NEW CREDENTIAL DIALOGUE
FIGURE 14. MANAGE ACCESS KEYS BLADE IN THE AZURE PORTAL
You are now ready to perform a SQL backup to Azure storage.
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:
FIGURE 15. SQL BACKUP WIZARD IN SSMS
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.
To back up a database to Azure storage using a T-SQL query, perform the following steps:
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.
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:
FIGURE 18. LAUNCHING THE RESTORE DATABASE DIALOGUE
FIGURE 19. CONNECT TO WINDOWS AZURE STORAGE DIALOGUE
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
FIGURE 21. RESTORE DATABASE DIALOGUE
As you can see, backing up and recovering SQL databases from backups stored in Azure is a straightforward process.
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:
Automated Patching:
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.
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.
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.
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.
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.
Each option is described briefly in the sections that follow.
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:
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 ConnectTM 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:
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:
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 ConnectTM 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.
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.