Microsoft has released the Update rollup 9 for Data Protection Manager 2012 R2 a little over one month back. This UR contains a number of significant improvements to the current DPM version thereby enabling more capabilities for your enterprise backup strategy.
Here are four reasons that you should consider to apply this UR.
No need for consistency check for file server backups in case of a DPM Filter corruption
When your production file servers encounter an unexpected downtime, DPM file tracking filter gets corrupted and results in an inconsistent replica. In UR9 DPM leverages USN journal to track the changes in files, thereby running a consistent check to repair the damaged filters is no longer needed. The repair operation will be displayed as a synchronization job in DPM which will also sync the replica to latest. Running a consistency check is really painful especially when the replica is huge.
Say Goodbye to Production Server Restart
One of the biggest headaches while upgrading the DPM agent is the requirement to restart the protected servers unlike SCOM or SCCM agents. Finally Microsoft has got rid of the restart requirement. Microsoft has eliminated all the causes for restarting servers while upgrading DPM agents except the filter driver update. Any backup products that perform incremental backups use a filter driver, and whenever there is an update to the filter driver a reboot is needed. If you are already on UR6 or above you can easily upgrade your DPM agents without the restart requirement. So unless any future UR doesn’t contain a filter driver update no restart required at all.
Cache Space for Online Backup has been reduced
In previous versions of Microsoft Azure Backup Agent local disk cache space requirement was 15% of the data source size for backup to Azure which is a big issue if your data source is over 10 TB. This has been reduced to 5% now.
Number of Recovery Points for Online Backups has been increased
For organizations with strict industry compliance requirements the need to have longer retention policies is a mandatory requirement. DPM now supports 9999 recovery points for a online backup in Azure where previously it was 366. This enables more flexible and consistent recovery policies for cloud backup.
You can refer the full KB article and download the binaries for UR9 package from here.
It’s been a while since my last blog post. I’m working on a DPM 2012 R2 test lab these days which I’ve planned to update to the latest UR version. When I checked for the latest UR7 got to know that the bits have been re-released.
As for the DPM team there is an issue in DPM 2012 R2 UR7 released on 28.07.2015 which causes expired recovery points on the disk were not getting cleaned up, resulting an increase in DPM recovery point volume after installing UR7. This re-release has addressed this concern and you can download the upadted bits via DPM 2012 R2 UR7 KB or Microsoft Update Catalog as of today.
OK I have updated to UR7 before 21.08.2015. Now what?
For those who are facing this dilemma should know that the re-released UR7 is not pushed via Microsoft Update and advised to manually install the new package on the DPM Servers with older UR7 package installed. The installation process will automatically execute pruneshadowcopiesDpm2010.ps1 PowerShell script which contains the fix.
There is no change in the DPM version (4.2.1338.0) in this re-release and it will remain same after the update. Also you will have to update the Azure Backup Agent to latest version (2.0.8719.0) prior installing DPM UR7 to ensure the integrity of your cloud backups after this release.
For those who like me updating to UR7 the old fashion way (wait for a month or two, lookout for bugs and then update) you’ve got nothing to worry.
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
Protection and Recovery
Windows Server 2012 R2 – Datacenter and Standard
Volumes, Files, Folders
Windows Server 2012 – Datacenter and Standard
Volumes, Files, Folders
Windows Server 2008 R2 SP1 – Standard and Enterprise
Volumes, Files, Folders
SQL Server – 2012, 2008 R2, 2008
SQL Server Database
SharePoint – 2013, 2010
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.