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.
- Data Source Size – The size of the database
- Retention Range – How many days you want to retain data for
- 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:
Now 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:
Now 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.