Azure Backup

Continuing my previous post about leveraging the public cloud for business continuity and disaster recovery scenarios, I’m going to expand on the capabilities of Azure Backup briefly.

If you’re interested in this subject, the best place to start is with the Azure documentation on the subject, found here:

There’s three primary scenarios where you can leverage Azure Backup:

  1. Direct to Cloud
  2. Local backups with frequent backup to cloud
  3. Cloud directly to cloud
Lists the components of Azure Backup: Azure Backup Vault, Backup Component (i.e. agent, backup service, or backup server), and the items that can be protected.

Azure Backup Components

Direct to Cloud

This scenario is prime for smaller environments. You simply install an agent on a server, connect it to Azure, and schedule your backups. The backup data is encrypted prior to leaving the VM, and is also encrypted in transfer. This is a good option for computers that aren’t frequently on your network, which may have important files kept on them – for example, users who frequently travel, work from home, or work in the offices of other companies frequently. Of course, using cloud storage or always-on connections such as DirectAccess are great options, but some people are more resistant to change than others, so it’s important to keep this data backed up.


  • easy to get started


  • no central management
  • heavy touch – each machine needs configuration, and management/monitoring isn’t centralized
  • no application awareness


  • small business – low server count
  • workstations that are infrequently connected to a central network
  • one-off servers that don’t really fit into existing backup topology – PoCs, or perhaps the oft-maligned bimodal IT
  • trial and PoC
  • Branch offices without the required infrastructure to support on-site backup servers

Local (On-Premises) Backups to Cloud

Most environments warrant some kind of central management infrastructure. With Azure Backup, this is achieved through System Center Data Protection Manager if you have System Center licenses, or Azure Backup Server, if you don’t have licenses. Azure Backup Server is basically a lightweight version of DPM, with the tape backup feature removed. It may also get more-frequent updates than DPM. Both Azure Backup Server and DPM are capable of creating application-consistent backups of SharePoint, SQL, and Exchange, as well as directly backing up Hyper-V virtual machines as a unit.

The data is stored locally on disks, for a specified period of time, and replicated to Azure for a separately-specified retention period. The Azure backups are encrypted prior to transfer, as with all the Azure Backup scenarios, and they are compressed as well – making for a very efficient transfer mechanism, in addition to DPM’s already efficient backup mechanism. If you have a large amount of data to seed, you can use Offline Seeding, which is essentially a process by which you mail Microsoft an encrypted hard disk with your initial seed.


  • Centrally managed – no need to manually visit every server
  • Application-consistent backups are possible
  • SCDPM can let you continue to meet compliance requirements with Tape Backup


  • local storage is required
  • larger networks will need careful thought to avoid saturating WAN links with backup traffic


  • Small, Medium, and Large Enterprise
  • Azure workloads with application-consistent backups
  • cloud and on-premises servers
  • Workstations that are frequently or always connected to your corporate network

For more information on backing up with Azure Backup Server, you can go here: If you’re interested in using System Center Data Protection Manager, you can read more here:

Cloud to Cloud

A frequent request I receive as a consultant focussing on Microsoft Azure deployments is how to best protect the workloads that are in Azure. This does require some nuance – if the you’re is already heavily-invested in an on-premises solution, that should be considered when assessing backup solutions.¬†However, there’s several good arguments to be made in favour of using Microsoft’s native tools. A critical advantage is that you do not need to pay for separate compute, egress, and storage charges – all the costs of backup and recovery are contained in the single monthly fee.

With Azure Backup, a backup extension is used to initiate a VSS snapshot and the changed data since the previous backup is transferred to the backup snapshot. For Linux VMs, the VM is backed up in a file-consistent state, so there may be some application data loss.

Azure Virtual Machine backup architecture diagram


  • Simple and¬†easy to use
  • Native
  • No additional costs – don’t need to pay for data egress (leaving the Azure DC) or compute (a VM running backup software)


  • Doesn’t work on-premises


  • Any supported VM running in Azure

For more information on backing up your Azure Virtual Machines, you can visit:

Leave a Reply

Your email address will not be published. Required fields are marked *