Posts Tagged ‘Data Protection Manager’

AlwaysOn Protection With System Center Data Protection Manager 2012 R2

Sunday, April 27th, 2014


I have been waiting for months to write this blog about how to protect AlwaysOn with DPM , the reason for the delay that DPM 2012 R2 before RU2 wasn’t supporting AlwaysOn  with Cluster. 

for Enterprises looking for true disaster Recovery and avoid single point of failure,  AlwaysOn can be setup using SQL Cluster Instance with a stand alone SQL server Instance.meaning the primary replica is hosted on a SQL Cluster instance and Secondary replica is hosted on SQL Instance Standalone. the reason for that is to avoid the single point of failure such as the SAN

As I mentioned earlier , before DPM rollup Update 2 for System center , DPM didn’t support Protecting AlwaysOn with Cluster Setup.

First step:  Install DPM Client to your WFC nodes , make sure to patch your DPM server with the latest RU2


Second Step: Create a Protection Group to protect databases on Clustered AlwaysOn .


DPM 2012 Sizing for SQL Backup

Tuesday, January 22nd, 2013

I recently came across an issue with sizing DPM allocations for backing up SQL 2012. It was fun, really. Anyway, here are the key things you need to know in order to properly size the storage for backing up SQL with DPM.

  1. Data Source Size – The size of the database
  2. Retention Range – How many days you want to retain data for
  3. Log Change Rate – This is how much your logs change on a daily basis. The default is 10% and     I cannot see a reason to deviate from that for most systems.

Once you have all this info you need to run it through two equations to determine both the replica volume size and recovery point volume size. I’m going to walk through an example here where we have a 90,346MB database and want 14 day retention with 10% log change and a 90% alert threshold.

To determine the storage requirements of the replica volume, we have to take the data source size, multiply it by (the log change percent + 1) and then divide that by (the alert threshold – .05). Looks complex, doesn’t it? It’s really quite simple. In our example case, the numbers work out as follows:

imageNow that we know we need roughly 114 GB for our replica volume, we can move forward to calculating the recovery point volume storage requirements. This is another, slightly longer but no more complex equation. 2.5 multiplied by the retention range in days multiplied by the log change rate multiplied by the data source size plus 1600MB. As you’ve probably guessed by now recovery point volumes have much larger storage requirements than replica volumes. The numbers for our example case work out as follows:

imageNow that we know we have roughly 310GB required for the recovery point volume, we’re going to need a minimum of 424GB to back up our 88GB database.  While I haven’t seen it anywhere as a MS best practice, I would recommend adding a 20% premium on top of the calculations and allow yourself room to grow.

You are putting this on SATA storage, correct? There is really know reason to put it on speedy FC or SAS.

Data Protection Manager 2010 Overview Poster

Saturday, March 24th, 2012

The Data Protection Manager (DPM) 2010 Overview poster was made to give an overview and quick reference to DPM’s components, architecture, and DPM protection scenarios. It consists of system requirements, licensing, architecture, supported workloads, storage
types, design quest