none
Yikes! 3.7TB is not enough to protect 714GB of files? RRS feed

  • Question

  • Last night I bumped up the storage pool size form 1.9 TB to about 3.7TB of disk space. Had problems migrating so i removed all the protection from DPM so nothing was listed in its database. I added a new protection group comprising the server with three partitions, four active VMs in one of its partitions, all the shares, all the system states, etc.

    Today, everything was protected except the system state on the host server and there was about 700GB of space available. Couldn't quite understand how to deal with the error messages (they were out of disk space messages but with over 5x the size of the protected data??)  so I removed the host from protection. A whole bunch of partitions were removed from the storage pool (didn't take a detailed inventory or anything - DPM creates about 60 or 70 partitions with meaningless names).

    After I re-adding the server, I have about 1.44GB of space left and a bunch of errors saying:
    "Synchronization jobs for C:\Program Files\Microsoft DPM\DPM\Volumes\Replica\File System\vol_398f0b62-09f3-40e3-a642-96cf883220ef on <server>.<domain>.local have failed. (ID: 3115)

    DPM is out of disk space for the replica. (ID: 58)"

    I've tried using the storage "calculator" but that doesn't seem to apply here.

    How much disk space does the storage pool need?

    Published documentation on Technet ranges anywhere from 1.5 times to 3 times.

    714GB x 5 -> 3.6TB and Im at 3.7TB and still not enough space.

    Thanks,
    Bob.

    Thursday, April 7, 2011 9:52 PM

Answers

  • Hi,

    Just for the replica DPM will use 1.5 times the amount of data on the source server.

    In your case that would be approx 1TB.

    For the recovery point the formula is : (Data source size x retention range in days x 2) / 100 + 1600 MB

    • Marked as answer by BobH2 Thursday, April 7, 2011 11:10 PM
    Thursday, April 7, 2011 10:23 PM

All replies

  • Hi,

    Just for the replica DPM will use 1.5 times the amount of data on the source server.

    In your case that would be approx 1TB.

    For the recovery point the formula is : (Data source size x retention range in days x 2) / 100 + 1600 MB

    • Marked as answer by BobH2 Thursday, April 7, 2011 11:10 PM
    Thursday, April 7, 2011 10:23 PM
  • Jeremy,

    Oh.

    Thanks.

    Bob.

    • Marked as answer by BobH2 Thursday, April 7, 2011 11:10 PM
    • Unmarked as answer by BobH2 Thursday, April 7, 2011 11:10 PM
    Thursday, April 7, 2011 11:08 PM
  • In case anyone`s curious:

    There`s even more to this than what Jeremy suggested.

    I removed all the protection groups, then picked a 20GB partition from a VM to protect. I checked all the boxes and shares I could find.

    DPM Allocated 1.3TB of partitions in the storage pool.

    It copied 236GB to tape.

    The tape has four distinct, separate backups of the same partition. I am doing a test restore to understand this better.

    Could not find any documentation (yet) that would explain pros and cons of each check box but it looks like with a little thought, one should be able to guess / determine the ones to use. (Not the ideal here for other people's corporate data.)

    There is published info scattered about though, just not comprehensive.

    Bob.

    Friday, April 8, 2011 11:26 AM
  • Did you tick the box "Colocate data" during the PG creation?
    Friday, April 8, 2011 11:57 AM
  •  

    Probably Not.

    Still trying to find out stuff - want to understand which check box(es) to use. Trade-offs: backup speed, End User Recovery, size, are some of the DPM server shares for DPM2DPM4DR?, etc. - not a lot of consolidated info out there.

    Finally figured out how to get the EUR tab up in a VM - have to use a share! But then a share from the DPM machine or VM? Still can't see previous copies from anywhere other than DPM recovery though.

    Ah! Just read what colocate does. I'll rebuild the protection group.

    Thanks,
    Bob.

    Similar results: allocated 1.4TB.
    Bob. 

     

    Ok. Spent the day surfing and experimenting.

    Individual VMs are listed as machines. Their drives and shares can be backed up. When a VM is added to a Protection Group and a partition has a share, the shared share is available for backing up.  If you backup that share, DPM creates additional backup partitions. Although a VM can be backed up this way, don’t need any of these. Backup speed: 25 MB/sec for drives and 44MB/sec for shares.

    The VMs can be backed up by backing up the entire Virtual Drive partition. Don’t need to and it creates more backup partitions (assuming other techniques are used). VHDs only can be restored, not VMs, and not files inside the VHDs (unless the VHD is restored and mounted first). Backup speed: 280MB/sec.

    Best is to backup VMs using the “\Backup using Child Partition Snapshot\VM-XX” option. The entire VM, just a VHD, or individual folders or files can be restored. When a VM is restored, so are its settings and saved memory. Excellent! Backup speed: 250MB/sec.

    Although co-locate is available, in my case, turning it off used less disk space plus gave one pair of partitions for each VM.

    Now turning my attention to "Replica is inconsistent" on host C:\ Drive.

    Bob. 

    Friday, April 8, 2011 5:00 PM
  • System State and WSB (Windows Server Backup)

    After a few more hours of surfing and experimenting, this is what I figure might be happening (someone please feel to correct me if I am wrong):

    In order to backup System State, DPM calls WBAdmin to start the WBEngine “Block Level Backup Engine Service”. WBEngine creates a System State backup (typically under 10GB) which can be replicated into the Storage Pool.

    It appears as if the path for the System State Backup is set the first time DPM runs a System State Backup. If the backup path for WSB is changed, DPM does not update its control file. The path is saved in the “<ComponentName>System Protection<FilesToProtect>” node of “%SystemDrive%\Program Files\Microsoft Data Protection Manager\DPM\DataSources\ PSDataSourceConfig.xml”.

    By updating PSDataSourceConfig.xml independently of the WSB settings, WSB and DPM can live independently, and keep their backup folders in separate partitions.

    If there is a problem with System State, the status of "Computer\System Protection\System State" will be "Replica is Inconsistent".

    An improvement to the DPM GUI might be to add a check box or radio buttons to allow the user to choose the standard WSB backup path, or to set an arbitrary path.

    I really do not know if a shared path will cause conflicts or not, haven't tried it, and do not intend to. Wouldn't hurt for someone to post their own results here or a link to a reference on this.

    The storage space I need now is down to 1379 GB, which is about 2x my primary partitions that need to be backed up, or about 1.6x the total size of my primary partitions.

    Bob.



    Saturday, April 9, 2011 2:36 PM