Azure Backup – Part 4 – System Center and Azure Backup

On the first post (see here), I explained how the Azure backup works. On this post, I’m explaining how to integrate Azure Backup with System Center Data Protection Manager.

If your environment contains a large number of systems that require protection, you might want to consider implementing Microsoft Azure Backup Server. Alternatively, if you have an existing implementation of System Center Data Protection Manager (DPM), you will likely benefit from integrating it with Azure Backup by installing the Azure Site Recovery agent on the DPM server.

These two methods generally yield equivalent results. Microsoft Azure Backup Server provides the same set of features as DPM except for tape backups and integration with other System Center products. Azure Backup Server also offers the same management interface as DPM. Effectively, by implementing Microsoft Azure Backup Server, you gain enterprise-grade protection without requiring System Center licenses.

With both of these products, you can provide recovery for Linux and Windows operating systems that run on-premises or in Azure, as long as an Azure Backup Server or DPM server resides in the same location. DPM and Azure Backup Server support consistent application backups of the most common Windows server workloads, including SQL Server, Office SharePoint Server 2013 or 2016, and Microsoft Exchange Server. They also deliver superior efficiency and disk space savings because of built-in deduplication capabilities.

It is important to remember that unlike the other Azure Site Recovery agent–based methods, neither DPM nor Azure Backup Server can back up data directly to an Azure Recovery Services vault. Instead, they operate as disk-to-disk-to-cloud solutions, using their local disks as the immediate backup target, and afterward, copying data to Azure from the newly created backup.

To integrate System Center DPM with Azure Backup, you must perform the following steps:

  1. If you do not already have an available Recovery Services vault, create a new one.
    Note: You can use the same vault for protecting Azure virtual machines with the Azure Backup VM extension and systems that run an Azure Site Recovery agent, including System Center DPM.
  2. Specify the vault’s storage replication type.
  3. Specify Backup goal settings, including the:
    – Location of the workload: On-premises
    – Workload type: any combination of Hyper-V Virtual Machines, VMware Virtual Machines, Microsoft SQL Server, Microsoft SharePoint, Microsoft Exchange, System State, or Bare Metal Recovery
  4. On the Prepare infrastructure blade of the Azure Recovery Services vault, select the Already using System Center Data Protection Manager or any other System Center product check box.
  5. Download the vault credentials from the Prepare infrastructure blade. The Azure Site Recovery agent uses vault credentials to register with the vault during the installation process.
  6. Download and install the Azure Site Recovery agent from the Prepare infrastructure blade. Start by clicking the Download link. Once the download completes, run the installation and register the local computer running System Center Data Protection Manager with the vault. As part of the registration, designate a passphrase for encrypting backups.
  7. From the Protection workspace of the DPM Administrator Console, create a new protection group or modify an existing one. Within the protection group settings, enable the Online Protection option.
    Note: You must enable short-term protection by using local disks. While you cannot use tapes for this purpose, you can additionally enable long-term protection to tape. As part of the protection group configuration, specify an online backup schedule, online protection data, online retention policy, and initial online backup methodology. Similar to the Azure Backup consoles, you can choose between performing initial backup over the Internet and using the Azure Import/Export service to copy it offline.

Deploying Microsoft Azure Backup Server requires that you perform the following steps:

  1. If you do not already have an existing, available Recovery Services vault, create a new one.
    Note: You can use the same vault for protecting Azure virtual machines with the Azure Backup VM extension and systems that run an Azure Site Recovery agent, including System Center DPM.
  2. Specify the vault’s storage replication type.
  3. Specify Backup goal settings, including the:
    – Location of the workload: On-premises
    – Workload type: any combination of Hyper-V Virtual Machines, VMware Virtual Machines, Microsoft SQL Server, Microsoft SharePoint, Microsoft Exchange, System State, or Bare Metal Recovery
  4. On the Prepare infrastructure blade of the Azure Recovery Services vault, make sure that the Already using System Center Data Protection Manager or any other System Center product check box is cleared.
  5. Use the Download link on the Prepare infrastructure blade to download the Microsoft Azure Backup Server installation media, which are over 3 GB in size.
  6. Download the vault credentials from the Prepare infrastructure blade. The Microsoft Azure Backup Server setup uses vault credentials to register with the vault during the installation process.
  7. Once the download of the Microsoft Azure Backup Server installation media completes, extract the download package content by running MicrosoftAzureBackupInstaller.exe, and then start the setup process.
    Note: The product requires a local instance of SQL Server 2014 Standard. You have the option of using the SQL Server installation media in the package or deploying an instance prior to running the setup.
  8. When prompted, provide the path to the vault credentials that you downloaded earlier. When registering the Microsoft Azure Backup Server with the vault, you can designate a passphrase for encrypting backups.
  9. Because Microsoft Azure Backup Server has the same administrative interface as the System Center DPM, after the setup completes, the remainder of the configuration is equivalent to the one referencing a System Center DPM, with the exception of tape backup–related settings.

Cheers,

Marcos Nogueira
azurecentric.com
Twitter: @mdnoga

Azure Backup – Part 3 – Backup Virtual Machines

On the first post (see here), I explained how the Azure backup works. On this post, I’m explaining how to backup Virtual Machines with Azure Backup.

If the systems that you want to protect are running the Windows or Linux operating systems on Azure virtual machines, then in addition to running Azure Site Recovery agent–based backups (as explained on the previous posts), you also have the option to perform a VM-level backup.

This process uses the Azure Backup VM extension and offers some additional benefits, including application consistency for Windows virtual machines, support for Linux, and a higher limit for the number of protected systems per vault, which is 200 Azure VMs versus 50 protected systems with the Azure Site Recovery agent. On the other hand, the backup frequency in this case is limited to once per day.

You should also keep in mind that the restore process creates a new virtual machine. As a result, an Azure VM–level backup does not provide a convenient option for restoring individual files or folders from a backup. In addition, the restore does not take into account such VM-level settings as network configuration, which means that you must recreate them after the restore. However, you can automate the restore process, by using Azure PowerShell or Azure CLI, for example. You must use scripting when recovering Azure virtual machines that host Active Directory domain controllers or that have complicated network configuration, including such characteristics as load balancing, multiple reserved IP addresses, or multiple network adapters.

Setting up an Azure IaaS VM-level backup by using the Azure portal involves the following steps:

  1. If you do not already have an available Recovery Services vault, create a new one.
    Note that the vault must reside in the same Azure region as the Azure IaaS virtual machines.
  2. Specify the vault’s storage replication type.
  3. Specify Backup goal settings, including the:
    – Location of the workload: Azure
    – Workload type: Virtual machine
  4. Choose the backup policy. The policy determines backup frequency and retention range. The default, predefined policy triggers the backup daily at 7:00 PM and has the 30-day retention period. You can create a custom policy to modify these values, by scheduling backup to take place on specific days and setting the retention period on a daily, weekly, monthly, and yearly basis.
  5. Specify the virtual machines to back up. The Azure portal will automatically detect the Azure virtual machines which satisfy Azure VM–level backup requirements. When you click Items to backup on the Getting started with backup blade, the Azure portal will display these virtual machines on the Select virtual machines blade. This will automatically deploy the Azure VM backup extension to the virtual machines you that select and register them with the vault.
  6. At this point, you can identify the Azure virtual machines that are backed up to the vault by viewing the content of the Backup Items blade.

Cheers,

Marcos Nogueira
azurecentric.com
Twitter: @mdnoga

 

Azure Backup – Part 2 – Azure Backup Agent

On the first post (see here), I explain how the Azure backup works. On this post, I’m explain how the files and folders are backup with the Azure Backup agent.

Azure Backup’s most basic functionality allows you to protect folders and files on 64-bit Windows Server and client operating systems, both on-premises and in Azure. This functionality relies on the Azure Site Recovery agent, which is available for download on the Azure Recovery Services vault interface in the Azure portal. You must install the agent on every system that you want to protect, and you must register it with the target vault.

To set up Azure Site Recovery agent–based protection from the Azure portal, perform the following steps:

  1. Create a Recovery Services vault.
  2. Configure the Backup Infrastructure storage replication type, by choosing either the Locally-redundant option or the Geo-redundant option on the Backup Configuration
  3. Specify Backup goal settings, including the:
    – Location of the workload: On-premises
    – Workload type: Files and folders
  4. Download the vault credentials from the Prepare infrastructure blade of the Azure Recovery Services vault. The Azure Site Recovery agent uses vault credentials to register with the vault during the installation process.
  5. Download and install the Azure Site Recovery agent from the Prepare infrastructure Choose the appropriate option for the system that you want to protect. In this case, you need to select the Download Agent for Windows Server or Windows Client option. When registering the local computer with the vault, you designate a passphrase for encrypting backups.
  6. Use the Azure Backup console to configure and schedule backups. After installing the agent, the new console, whose interface closely matches the native Windows backup console, becomes available. This allows you to select files and folders to back up and to schedule a backup directly to the Azure Recovery Services vault. You can also use Azure PowerShell to configure and initiate backup operations. After you schedule a backup, you also have the option to run an on-demand backup.

Note: If the computer that you want to protect contains a large amount of data and you have limited bandwidth in your Internet connection to Azure, consider using the Azure Import/Export service to perform the initial backup. In this approach, you copy the data to back up locally to a physical disk, encrypt it, and then ship the disk to the Azure datacenter where the vault is located. Azure then restores the content directly to the vault, which allows you to perform an incremental rather than full backup following the registration.

Cheers,

Marcos Nogueira
azurecentric.com
Twitter: @mdnoga

 

Azure Backup – Part 1

One of the first workloads that usually the majority the organizations wants to start to use in Azure is to replace the tape to Cloud Backup. Following the best practices for the backup strategy is Disk-Disk-Cloud. This strategy replaces the previous one, where we use the last place of the backup to a tape. With Cloud backup as the last resource we are leveraging the cloud storage capabilities and resilience.

The Azure Backup service uses Azure resources for short-term and long-term storage to minimize or even eliminate the need for maintaining physical backup media such as tapes, hard drives, and DVDs. Since its introduction, the service has evolved from its original form, which relied exclusively on a Windows Server backup agent that was downloadable on the Azure portal, into a much more diverse offering. The Azure Backup service includes:

  • A Windows 64-bit Server and Client file, folder-level backups with the Azure Site Recovery agent, and the Online Backup integration module for Windows Server 2012 R2 Essentials.
  • Long-term storage for Data Protection Manager with the Azure Site Recovery agent.
  • Long-term storage for Windows application-level backups with Microsoft Azure Backup Server.
  • Windows-based and Linux-based Azure IaaS VM-level backups with the Azure VM Backup extension.

Recovery Services vault

Regardless of the backup functionality that you intend to implement, to use Azure Backup to protect your data, you must first create a Recovery Services vault in Azure. A vault is the virtual destination of your backups, which also contains configuration information about the systems that Azure Backup protects. To protect a system, you must register it with a vault. The vault should reside in an Azure region that is close to the physical location of the data, and in the case of Azure IaaS virtual machines, in the same region.

Two resiliency options are available when creating an Azure Recovery Services vault: locally redundant and geo-redundant. The first option is based on locally redundant Azure Storage, consisting of three copies of backed-up content in the same Azure region. The second option is based on geo-redundant Azure Storage, including three additional copies in another Azure region, providing an additional level of protection.

Note: You should set this option as soon as you create the vault, since will not be able to change it as soon as you register the first of your systems with the vault.

An Azure subscription can host up to 25 vaults. Each vault can protect up to 50 computers that run the Azure Site Recovery agent or the Online Backup integration module. Alternatively, if you back up Azure IaaS virtual machines by relying on the Azure IaaS VM Backup extension, the vault can protect up to 200 computers.

Note that there is no limit on the amount of data in the vault for each protected computer. There also is no limit on the maximum retention time of backed up content. However, there is a restriction on the size of each data source: about 54,000 GB for Windows 8, Windows Server 2012, and newer operating systems. The maximum backup frequency depends on the configuration, with up to three backups per day with Windows Server and Client Azure Site Recovery agent, up to two backups with Data Protection Manager or the Microsoft Azure Backup Server, and a single backup when using IaaS VM extension–based setup.

All backups are encrypted at the source with a passphrase that the customer chooses and maintains. There are no additional charges for the traffic generated during backup, both ingress, into Azure and during restore, egress, out of Azure.

Note: Azure Backup relies on the same agent as Azure Site Recovery, which later topics in this module will discuss. This is the reason for the references to the Azure Site Recovery agent in this lesson. Both Azure Backup and Azure Site Recovery also store data from systems they protect by using an Azure Recovery Services vault. A single vault can simultaneously serve as the repository for Azure Backup and Azure Site Recovery.

Cheers,

Marcos Nogueira
azurecentric.com
Twitter: @mdnoga

 

How to monitor and manage Azure Classic Virtual Machines

On the last post, I talked about why you should use the classic virtual machines. Could be a lot of reasons or could be the way that you already started a few years and all of your deployment process is built on top of the Azure Service Management model. Saying that, now you have to manage and monitor those workloads.

In general, the concepts applicable to managing disks and images of classic virtual machines have not changed significantly with transition to the Azure Resource Manager deployment model. However, there are a few important differences that you must consider:

  • Classic VMs require a classic Azure storage account to host their disks. Similarly, you cannot deploy a classic VM by using an image hosted in an Azure Resource Manager storage account.
  • To identify classic VM images, you need to reference them by the name of the corresponding VHD file. This changed with the Azure Resource Manager model.

Command line management of classic VM disks also differs from managing their Azure Resource Manager counterparts, because they use a different set of Azure PowerShell cmdlets.

Starting with Azure PowerShell 1.0, Azure Resource Manager-cmdlets use the -AzureRm substring in place of the -Azure substring present in the Service Management cmdlets. For example, to add a data disk to a classic VM, you would use Add-AzureVMDataDisk, but to apply the same change to an Azure Resource Manager VM, you would run Add-AzureRmVMDataDisk.

Monitoring options of classic VMs do not differ significantly from the functionality available to Azure Resource Manager VMs. The same capabilities are exposed in the Azure portal, including metrics, diagnostics, and alerting. The only exception is support for boot diagnostics (providing console output and screenshot support) that depend on Azure Resource Manager.

As far as operating system management is concerned, while both Azure Resource Manager and classic deployment models provide matching features in this area, the implementation details of each are different. This is primarily due to the different set of supporting Windows PowerShell cmdlets and lack of support for template-based deployments for classic VMs. In addition, Service Management-based Azure PowerShell scripts are relatively simpler, allowing you, for example, to leverage default storage account of your Azure subscription for storing Custom Script extension scripts or DSC configuration archives.

It is important to note that, just as with Azure Resource Manager VMs, both Custom Script extension and Desired State Configuration–based management are available for classic VMs running both the Windows and Linux operating systems.

Cheers,

Marcos Nogueira
azurecentric.com
Twitter: @mdnoga