This post is based on my direct experiences planning and implementing WAB and DPM+WAB. All my findings are true today, as you know cloud services are improving and changing fast.
Now that the Windows Azure Backup (WAB) pricing has changed the convenience of using Azure as secondary backup starts to get to a fair level. I’m currently working with customers that want to leverage WAB in three different scenarios:
- As a secondary offline copy alternatives to tapes – using DPM integration
- As their primary data protection method for VMs running on Azure
- As their long term protection for VMs running on Azure, where short term and continuous backup is delivered through a DPM server running also on Azure
Scenarios 2 and 3 require an explanation, why use DPM on Azure and not just WAB? There several reasons basically involving protected workloads, Recovery Point Objective (RPO) and management:
- WAB supports just the file system VSS, it doesn’t have any workload specific integration: SQL Server, Active Directory, Sharepoint farms. So if you want to achieve a smooth backup of these workloads without first dumping data on disk using workload specific tools, you need to use a different product. DPM is such a product.
- Linked to topic 1. if you want to achieve “continuous” backup with short RPOs (15’) WAB is not your product, again you need DPM. If you check how much time takes the WAB agent to initialize a copy you can understand why you cannot have RPOs in the minutes.
- WAB doesn’t have a centralized way to deploy agents and protection policies, you need to install and configure WAB for every single VM. This can be automated via the POSH cmdlet, but it must be done.
- WAB doesn’t have a central monitoring console where issues, throughput, performance and so on can be tracked. OpsMgr can be used for such a task, but with a community MP.
Just to be crystal clear WAB has a central console but only for VM snapshot backups.
Things to consider and resources
WAB interacts with the VSS file system provider, no other VSS providers are in scope today.
Not all the workloads are in the compatibility matrix from DPM to Azure backup: https://msdn.microsoft.com/en-us/library/azure/jj860400.aspx. I think for the most of them is just a documentation mismatch, but nevertheless the compatibility matrix must be taken into account.
Currently the maximum size for a protected datasource via DPM is 1.65 TB, this limit should be removed with System Center 2012 R2 DPM UR7.
Licensing as I know it
Licensing is based on “instances” and actual storage used. The latter is priced at blob level, the cheapest storage available today on Azure.
To have a gross estimate of the cost of moving your DPM datasources to WAB there’s an handy solution here: http://blogs.technet.com/b/dpm/archive/2015/04/01/tco-reduction-with-the-azure-backup-pricing-in-dpm-deployments.aspx
If you want to use DPM, it must be licensed. The licensing is embedded in System Center so you actually need to license system center, for more information on System center on Azure see: http://azure.microsoft.com/en-us/pricing/licensing-faq/
Implementing both VM snapshot protection and in guest data protection causes the single VM to be counted as two instances. This is silly in my opinion and I hope this will change in the near future.
Instance size is based on actual data used by the VM and not on allocated size. This is true for both DPM orchestrated and Azure Virtual Machines directly serviced by WAB.
This posting is provided “AS IS” with no warranties, and confers no rights.