Replica inconsistent and insufficient disk space on BMR (Bare Metal Recovery) Backup (How To Fix)

Replica inconsistent and insufficient disk space on BMR (Bare Metal Recovery) Backup (How To Fix)

System Center Data Protection Manager 2010 (DPM 2010) offers with its new console in the creation of a protection group in System Protection, a new option called "Bare Metal Recovery".

This option saves the operating system files (System State) and critical volumes (excluding user data) to restore it very quickly to new hardware.  This feature existed in DPM 2007 with Software Removal Tool.

The problem is that sometimes the BMR backup "Bare Metal Recovery" is not working properly and fails with the message "Replica inconsistent" caused by "insufficient disk space".


DPM 2010 does not calculate the size of BMR data source, but assumes 30 GB for all servers. Admins should change the value as per the size of BMR backups expected on their environments.

The size of BMR backup is approximately equal to the amount of space used on all critical volumes.

Critical volumes = Boot Volume + System Volume + Volume hosting system state data such as AD DIT/log volumes. 


We need to run the BMR backup Manually (without DPM) to know the disk size needed on DPM:

1. Create a shared folder with enough space to store the BMR backup, for example \ \ server_name \ BMR
2. On the production server, launch the command prompt with administrative privileges
3. Then type the following command:

wbadmin.exe start backup -allcritical -quiet -backuptarget:\\server_name\bmrshare 

4. Once the backup is complete, check the disk space consumed by the BMR backup and make sure that the same amount of disk space or more have been allocated to the replica volume.
5. Also increase the disk space of volume recovery point.
6. Then in the DPM console, starts the consistency check on our replica inconsistent
Once these operations are completed the BMR backup will be created and recovery points are available.

External Link :

Sort by: Published Date | Most Recent | Most Useful
  • I have to say for a purely Microsoft-based backup solution, backing up a purely Microsoft server, it is ridiculous that it can't calculate the BMR automatically and effectively. If an end-user can do it manually using a Microsoft tool, then a mature, premium Microsoft backup product should be able to. So if I have 100 servers to back up with BMR, Microsoft expects me to run 100 trial manual backups just to figure this out?????!

  • As I understand it, the issue is that DPM doesn't directly do the BMR backup, it basically calls wbadmin and uses that to perform the actual backup on the protected server. Therefore if wbadmin isn't able to determine the space required (without running a backup to another source first like above) then neither is DPM. Since the BMR backup excludes user files, wbadmin and DPM can't simply look at the amount of space used on C:\ to get a figure. It presumably needs to scan through all the files on there and determine which are system files and which are user files.

  • I would like clarification on the statement "make sure that the same amount of disk space or more have been allocated to the replica volume".

    Our replica volumes are set to grow automatically and there is ample unallocated space in the storage pool. So why am I getting an insufficient disk space error when I know there is plenty of room for the BMR. Other articles have stated that the BMR doesn't get saved locally WSB (, so if that's the case why am I getting this error? Is there something in DPM that needs to be adjusted to manually increase the replica volume?

  • eroseland: DPM will only grow the volumes by 25% each time (see, so if that increase isn't enough to encompass the space requirements then you'll continue to get an error. Eg, if DPM has guessed that you'll need 10GB, but there's actually 50GB requiring backup, then it will fail due to insufficient disk