none
DPM 2007 Replica creation of very large drives RRS feed

  • Question

  • Hi, I'm creating a protection group of a file server that has a 4 TB hard drive. When going through the protection group creation, and setting the retention to 1 day and to syncronize just before the recovery point, DPM 2007 is asking to make a replica size of 5.8 TB and a recovery point volume of 79 GB. Is there a reason why DPM needs to have almost 2 TB of extra space for the replica? The 4TB drive will stay the same and not get bigger. Currently the drive has 3.9TB used. Any information will be appreciated.
    Wednesday, July 28, 2010 2:09 AM

Answers

  • Yes, in my experience your issue is because you have a 32-bit server with a volume size over 1TB.  The farther over 1TB the volume capacity is, the more likely you are to run into issues.  The problem is with the VSS system, not DPM itself.  Rebooting the protected server will "fix" the problem for a short time. The only true solution is to change the OS to 64-bit.

     

    http://technet.microsoft.com/en-us/library/bb878056.aspx

    The problem is that 32-bit operating systems only provide 256MB for the NonPagedPool (NPP), regardless of how much RAM is in the system.  VSS snapshots require 8MB of contiguous NPP memory per TB of volume capacity.  Over time the NPP gets fragmented so it gets more and more difficult for the OS to allocate a contiguous block and VSS starts to fail.

     

    Thursday, August 5, 2010 9:34 PM

All replies

  • The DPM 2007 GUI is a pain in this regard.  It pretty much requires you to have 2.8x the total used space of a volume free in your storage pool in order to add it, EVEN IF you modify the allocation sizes and reduce it to a more reasonable number (which can be satisfied by your the space in the storage pool).

    DPM 2010 doesn't do this.  If you modify the allocation sizes and choose smaller values that can be satisfied by the storage pool, it let's you proceed.

    Fortunately there is a workaround I have used with DPM 2007. It requires you to set up protection in two stages:

    First stage is to select only one small folder on the volume (be sure not to select the root of the volume).  I recommend creating an empty folder for this step (you can delete the folder later once you are finished with everything).  When you get to the “Review disk allocation” section, the default disk allocations will be 2.8 times the total used space on the entire volume.  Press the “Modify” button to change allocations.  Since you did not check the root of the drive, you can click the “Calculate” link.  It will scan that one small folder you selected and change the default allocations based on the actual size of that one folder.  Set the allocations to what you really want them to be based on the data set size that will ultimately be protected by DPM.  Make sure you use a manual replica creation method and save changes to the protection group.

    Second step is to now go in and modify that protection group again.  Change the directory selection to what it should really be.  You can now select the root of the drive, add the large folders, or whatever the case may be.  DPM does not present the “review disk allocations” screen when you are modifying a group, so you will not reach that impasse when it demands that 2.8x space be available in the pool.  Submit your changes to the protection group.

    Be warned that DPM will trigger a consistency check after that second step, so you will most likely want to immediately cancel that job if you are seeding via USB.  If you are doing it over a LAN, then no worries...let the consistency check do its thing.

    Let me know if you have any questions.

    • Edited by Rod Savard Wednesday, July 28, 2010 3:39 AM
    • Proposed as answer by Rod Savard Tuesday, August 3, 2010 12:36 AM
    Wednesday, July 28, 2010 3:36 AM
  • BTW, the 2.8x figure is because we use the max retention period of 64 snapshots.  When you do that it really exacerbates this problem....DPM demands an insane amount of space for the replica and recovery point volumes.
    Wednesday, July 28, 2010 3:38 AM
  • thanks for the reply Rod. Since I know that the volume will not go above 4TB, can I go in and shrink the volume since it is on a Windows 2008 server?
    Thursday, July 29, 2010 7:53 PM
  • DPM 2007 does not support shrinking volumes.  Since you just set this up, I would remove protection, delete the disk volumes, and start over.

    Do not use disk management to try and shrink volumes. DPM 2010 does support shrinking volumes but I haven't personally tested it.

    Thursday, July 29, 2010 9:16 PM
  • thanks for the info Rod. I've used your method for creating a protection group for the large volume before. And it lets me create the volume, but the problem I'm running into if I am too stringent with the free space, is I will constantly get resource alert ID 104 (Insufficient system resources exist to complete the requested service) in DPM when trying to syncronize and create recovery points. I don't know which resource it is refering too, but it seems if I add additional space to the replica volume, then the sync will work. Does this seem correct?

    Monday, August 2, 2010 11:33 PM
  • When you get the insufficient resource message, what percentage of the replica volume is available?  You will get a notification when it reaches 90% full (but it's not the insufficient resource message).

    I have seen insufficient resource messages due to issues with the protected server though.  Tell me, is this protected server 32-bit or 64-bit?  We have often seen issues with 32-bit servers that have very large volumes (even if the volumes are not utilized too much).  MS recommends any server with a volume capacity of 1TB or greater should be 64-bit.  The VSS subsystem on 32-bit servers can run out of resources otherwise.  (DPM relies on VSS.)

    Tuesday, August 3, 2010 12:35 AM
  • The protected system is a 32bit Windows 2003 box. The Protection group has a Replica volume of 5.8TB allocated and 3996.78 used. The recovery volume is 75GB allocated and 3GB used. By these numbers both of these volumes have larger than 10% free space (in DPM).

    The actual drive is 4TB so you can see that there isn't alot of free space on the drive, but I was experiencing this issue when I had more than 10% free space on the protected drive.

    Your statement about using 64bit with the larger shares makes sense and might explain the issues I've had. Is there a way in the event logs that would show this is the cause of my issues with DPM backing up the server?

    Thursday, August 5, 2010 7:30 PM
  • Yes, in my experience your issue is because you have a 32-bit server with a volume size over 1TB.  The farther over 1TB the volume capacity is, the more likely you are to run into issues.  The problem is with the VSS system, not DPM itself.  Rebooting the protected server will "fix" the problem for a short time. The only true solution is to change the OS to 64-bit.

     

    http://technet.microsoft.com/en-us/library/bb878056.aspx

    The problem is that 32-bit operating systems only provide 256MB for the NonPagedPool (NPP), regardless of how much RAM is in the system.  VSS snapshots require 8MB of contiguous NPP memory per TB of volume capacity.  Over time the NPP gets fragmented so it gets more and more difficult for the OS to allocate a contiguous block and VSS starts to fail.

     

    Thursday, August 5, 2010 9:34 PM