Disk Allocation - Keeps Wanting More Space RRS feed

  • Question

  • We use DPM 2007 in our Prod and DR centers. 

    In Prod DPM, there is a particular protection group that backs up one of our file servers.  I'll call it prod-file01 for now.  This file server replicates its data to a DR file server (which I'll call for now, DR-file01) using the native DFSR.  The DR DPM then backups DR-file01.  More or less, give or take a couple of DFSR backlogs here and there, the 2 file servers are identical.

    The Prod DPM has a protection group for prod-file01 with disk allocation set to 1.5 TB for replica and 250GB for recovery point volumes.  No problems there.

    The DR DPM had the same configuration setup for its protection group for DR-file01.  However, over time, we keep getting alerts that the recovery point volume in DR had its space threshold exceeded and we keep having to increase the allocated space on it.  The DR DPM protection group for DR-file01 now has, to date, 1.5TB for replica and 2 TB for recovery point volumes.

    If the 2 file servers are identical, why is the Prod DPM okay with a 250GB recovery point volume but the DR DPM keeps wanting more?

    We have tried to stop the DR DPM's protection group and re-create it.  Still, over time, it keeps wanting more.  The protection groups are identical, the data sets on the file servers are identical, etc. Very confusing.  Has anyone seen this behavior before?

    Both DPM Servers - Windows 2008 SP2, with DPM 2007 (Build: 2.0.8864.0).

    Both File Servers - Windows 2008 SP2, with DPM Agents (Build: 2.0.8864.0).




    Tuesday, September 21, 2010 2:28 PM

All replies

  • Hey,

    Just a guess here, but is the dfsprivate folder excluded?


    Mike Resseler

    Visit System Center User Group Belgium @ and
    Tuesday, September 21, 2010 6:40 PM
  • Hey Mike, thanks for the feedback.

    Our data sits on the D: drive of each server.  "No", the DFSRPrivate folders are not excluded from DPM backup.  While DFSRPrivate stayed in its original default locations, the Staging areas were relocated to separate volumes on each server (E: drive of each server) to increase overall system performance for DFSR.

    So the only DFSRPrivate "stuffs" getting backed up are the "other" subfolders.  But when we check on the target DR side, the largest folder is only the "Conflicted and Deleted" and that only amounts to roughly 463MB.

    So it probably would/could make sense for us to exclude them from backup but it wouldn't account for the difference between the 250GB recovery point volume in prod vs. the 2TB recovery point volume in DR. 

    This is such a strange one.  Help!



    Tuesday, September 21, 2010 7:05 PM
  • Hi

    I noticed in your first note that the PG's are the samt config, but I must ask. Does your PG have the same configuration? Samt Retention rate, recovery point creation etc.?

    I had a similar case on one of my customers, the problem was the same, a protected member needed more space over and over again. The problem was that the PruneShadowCoipes.PS1 script didn't run. Have you alterd this configuration for som how? Like set another time for the script to run? Open the DPM PowerShell and run the script on the affected server, this will take some time.

    Get back with info =)


    Robert Hedblom

    Check out my DPM blog @

    Tuesday, September 21, 2010 7:44 PM
  • Robert:

    Thanks for the feedback.  Good point - I should better clarify. Protection Groups are mostly the same.  Both PG's have the same retention, number of recovery points, etc.  The lone difference is that they run the recovery points at different times throughout the day. So Prod could let's say run at 7am, 12pm and 7pm.  DR DPM could be running it let's say at 10am, 3pm and 10pm.  Something like that... So more or less they are the same.

    We have not altered anything but on the same note, we have never manually tried running the PruneShadowCopies.PS1 script.  Is this something that DPM normally would do on its own?  Or is this a script that should explictly be scheduled to run on a recurring basis?


    Tuesday, September 21, 2010 10:17 PM
  • Hi Dave!

    The PruneShadowCopies script runs by deafult every day at midnight on a DPM server, but sometimes the DPM server need a push in the right direction =)

    You can read about the script on my blog:

    Run the script and get back with info.



    Robert Hedblom

    Check out my DPM blog @

    Wednesday, September 22, 2010 9:31 AM
  • Sorry Robert, it didn't work.  The volume still shows that it only has 10% free.  Could there be something else you can think of?  The retention looks like it's working because from the Recovery view, I only see the correct number of days that I can restore from.  Very confusing!
    Saturday, September 25, 2010 12:58 AM
  • Are there large differences in the amount of data transferred shown for corresponding synchronization jobs? That is, are the synchronization jobs for server prod-file01 averaging say 50MB whereas the synchronization jobs for dr-file01 are 500MB?

    From what I can gather, when a new/changed file is replicated from prod-file01 to dr-file01, the file on dr-file01 is overwritten with the replicated staged copy.

    DPM file protection works by using VSS to protect files that have changed and synchronizes those changes to the DPM replica and ultimately the difference between the replica and previous recovery point gets stored as a new recovery point. My theory would be that the synchronizations are much smaller in size between prod-file01 and Prod DPM than they are from dr-file01 to DR DPM since prod-file01 is having a few block level file changes made and the replicated DR-file01 is having the entire changed files rewritten.

    You may be better off with a secondary DPM server protecting the original Prod DPM replica of prod-file01 as far as storage is concerned. It may be a little more network bandwidth to perform the daily replications, so which is more valuable -- network bandwidth or drive capacity?

    Wednesday, October 13, 2010 9:44 PM
  • TalokEchelon, whoa, sorry. I completely forgot to check back on this. Yes, we're still having problems.

    But no the amount of data transferred between the 2 servers during synch jobs are the same.  If on a given day prod synchs 500MB, then in DR, it'll be the same 500MB...



    Tuesday, November 16, 2010 10:17 PM