For those folks who are running their VMs in Microsoft Azure, I have some good news today. Running System Center Data Protection Manager in a Azure VM to protect Azure VM workloads is now fully supported. Of course Microsoft guarantees that data (including VHDs) are replicated three times within a data center to ensure high availability, but what about your local compliance policy that requires the management to see the actual backups? Now this comes handy in scenarios like that.
Now lets take a look at the supported scenarios in this model.
- You can install DPM on any Azure VM that is A2 or higher. You can check Azure VM sizing details from here.
- DPM in Azure can protect workloads across multiple cloud services as long as they are in the same virtual networks and subscription.
- The size of the DPM storage pool depends on the size of the VM. Currently the maximum number of data disks supported by an Azure VM is 16 making the maximum size of the pool to 16 TB.
Wait! this is the real catch. Not all workloads supported by an on-premise DPM is available in Azure DPM. Below table lists only the supported context in Azure.
|DPM 2012 R2||DPM 2012 with SP1||DPM 2012||Protection and Recovery|
|Windows Server 2012 R2 – Datacenter and Standard||Y||N||N||Volumes, Files, Folders|
|Windows Server 2012 – Datacenter and Standard||Y||Y||N||Volumes, Files, Folders|
|Windows Server 2008 R2 SP1 – Standard and Enterprise||Y||Y||Y||Volumes, Files, Folders|
|SQL Server – 2012, 2008 R2, 2008||Y||Y||Y||SQL Server Database|
|SharePoint – 2013, 2010||Y||Y||Y||Farm, Database, Frontend web server content|
There are some best practices and guidelines that you may want to follow if you wish to deploy DPM in Azure IaaS. Let me explain them as simple as I can.
- It is recommended to use a VM is the Standard Tier rather than the Basic Tier since the maximum IOPS per disk is much higher in the Standard Tier. Backup tasks are IOPS eaters so you may will have to take this as a rule of thumb.
- A separate storage account for the VM running DPM is recommended. Again this is to ensure that the VM can fully utilize IOPS & size constraints of a storage account rather than sharing same with an existing storage account which as running VMs. If you use a shared storage account there is high chance that you run into performance bottlenecks.
- Offload your data older than a day to Azure Backup and keep the latest in the DPM data disks. Again by doing this you ensure storage account consumption is minimal along with longer retention period. This way you won’t be needing to scale the storage for Azure VM.