none
DPM Large Protected Databases RRS feed

  • Question

  • Good Morning,

         I have a few questions regarding DPM 2012 and the way it protects Exchange databases. I had a bad mobile device generating 1000's of logs on a DB in Exchange and filling up the transaction logs rapidly. DPM backed all of that up. The problem is now my once 800GB DB Recovery volume in DPM is 2.2TB used and 4.2 TB unallocated. 

    1. Is there any way to get all of that space back? 

    2. Will we start to see the storage pool increase when retention is met? Start to reclaim space?

    3. Is there a recommended percentage of storage we should have free on the storage pool in order for DPM to not see VSS errors or inconsistency?

    Thanks

    Monday, December 23, 2013 1:22 PM

Answers

  • Hi,

    DPM leverages VSS shadow copies in order to make point-in-time recovery points. As noted, DPM did make the desired recovery points and copied all those logs over to the DPM servers replica.  In order for VSS to maintain the recovery points that have the boated log files in case they needed to be restored at a later time, VSS will copy those logs to the recovery point volume which as noted will bloat the recovery point volumes until which time that recovery point can be deleted.

    Q1. Is there any way to get all of that space back? 
    A1. Not right away, but soon after the recovery points expire, the recovery point volumes "used space" will be reduced automatically, and then you can try to shrink the recovery point volume to get the reclaimed space back into the storage pool.

    Q2. Will we start to see the storage pool increase when retention is met? Start to reclaim space?
    A2) The storage pool will only see the free space added after you manually "shrink" the recovery point volume once the recovery points expire that represent the bloated log files.

    Q3. Is there a recommended percentage of storage we should have free on the storage pool in order for DPM to not see VSS errors or inconsistency?
    A3. Not necessarily, Storage pool usage is dependent on too many variables and can be depleted quickly for problems like what you described, unexpected data churn or excessive log creation like you experienced.  temporary spikes like that are hard to plan for.


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. Regards, Mike J. [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.

    Thursday, December 26, 2013 8:30 PM
    Moderator
  • Hi,

    Yes, it sounds like you are at the hairy edge of the space required to maintain the recovery points for the desired retention period.  Once you reach equilibrium where the size of the recovery points being deleted for a day equals the size of new recovery points created for the day are equal, then no more growth of the recovery point volume will be required.  The Log bloat issue you had is not normal and will skew the storage requirements until you are back to normal, so I would not try shrinking again until the bloated recovery points expire are eventually deleted.

    Auto-grow will grow volumes as needed in increments of 10GB or 25% of the current volume size which ever is greater.  If you want more control over the growth, disable the autogrow checkbox for that data source.

    Right-click the datasource under the protection group.  Select modify disk allocation, then uncheck the autogrow checkbox.


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. Regards, Mike J. [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.


    Friday, December 27, 2013 6:13 PM
    Moderator

All replies

  • Hi,

    DPM leverages VSS shadow copies in order to make point-in-time recovery points. As noted, DPM did make the desired recovery points and copied all those logs over to the DPM servers replica.  In order for VSS to maintain the recovery points that have the boated log files in case they needed to be restored at a later time, VSS will copy those logs to the recovery point volume which as noted will bloat the recovery point volumes until which time that recovery point can be deleted.

    Q1. Is there any way to get all of that space back? 
    A1. Not right away, but soon after the recovery points expire, the recovery point volumes "used space" will be reduced automatically, and then you can try to shrink the recovery point volume to get the reclaimed space back into the storage pool.

    Q2. Will we start to see the storage pool increase when retention is met? Start to reclaim space?
    A2) The storage pool will only see the free space added after you manually "shrink" the recovery point volume once the recovery points expire that represent the bloated log files.

    Q3. Is there a recommended percentage of storage we should have free on the storage pool in order for DPM to not see VSS errors or inconsistency?
    A3. Not necessarily, Storage pool usage is dependent on too many variables and can be depleted quickly for problems like what you described, unexpected data churn or excessive log creation like you experienced.  temporary spikes like that are hard to plan for.


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. Regards, Mike J. [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.

    Thursday, December 26, 2013 8:30 PM
    Moderator
  • One more question on this:

    When I shrink them, it seems like at each incremental sync, the recovery point volumes just grow back to the allocated size they were before. We have auto-grow set, and it seems DPM thinks it needs to allocate back to the size it was before the shrink.

    Is there any way to stop that? 

    Or once we get deep into retention roll off's will I be able to shrink it and it only grow a little at a time?

    Thanks so much for your answers to all of my DPM questions!

    Friday, December 27, 2013 12:16 PM
  • Hi,

    Yes, it sounds like you are at the hairy edge of the space required to maintain the recovery points for the desired retention period.  Once you reach equilibrium where the size of the recovery points being deleted for a day equals the size of new recovery points created for the day are equal, then no more growth of the recovery point volume will be required.  The Log bloat issue you had is not normal and will skew the storage requirements until you are back to normal, so I would not try shrinking again until the bloated recovery points expire are eventually deleted.

    Auto-grow will grow volumes as needed in increments of 10GB or 25% of the current volume size which ever is greater.  If you want more control over the growth, disable the autogrow checkbox for that data source.

    Right-click the datasource under the protection group.  Select modify disk allocation, then uncheck the autogrow checkbox.


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. Regards, Mike J. [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.


    Friday, December 27, 2013 6:13 PM
    Moderator