First published on TECHNET on Apr 14, 2017
There may be circumstances where the replica volume for a protected data source is under allocated or a very large increase of protected data results in synchronization or recovery point job failures due to inadequate space on the replica.
Some common examples of where this might occur are explained below.
Bare Metal Restore (BMR) protection.
In DPM, BMR protection covers protection for operating system files (System State) and critical volumes (excluding user data). DPM does not calculate the size of BMR data source, but assumes 20 GB for all servers. At the time of protection this cannot be changed in the disk allocation page when using Modern Backup Storage (MBS).
Admins can change the default replica size as per the size of BMR backups expected in their environments. This is a global setting and effects all future BMR replica allocation size.
Size of BMR backup can be roughly calculated sum of used space on all critical volumes.
Critical volumes = Boot Volume + System Volume + Volume hosting system state data such as AD DIT/log volumes.
To help calculate the size of a BMR for a protected server, run the following command on that server then total up the used space for the volume(s) listed.
C:\>wbadmin.exe start backup -allcritical -backuptarget:\\server\bmrshare
This should show you the list of volumes included in the BMR backup and ask "Do you want to start the backup operation?. - Type N to exit then total all the used space on the volumes listed minus the page file size if one is hosted on a critical volume. Alternately you can Type Y and let the BMR backup continue and once finished check the size of the WindowsImageBackup folder on the target share.
To change the default replica size for ALL future BMR protection use the following registry key:
HKLM\Software\Microsoft\Microsoft Data Protection Manager\Configuration
However, if you only need to increase the replica for a subset of servers or are having problems getting a good initial replica for one, you can use the information in this article to manually increase the specific replica volume(s).
There may be a time when you want to migrate users between mailbox databases or between exchange servers. During migration, there will be a large increase in the number of exchange logs created and an increase in the size of the destination mailbox database(s). These large increases in a short period of time can result in DPM backup failures if the replica cannot be grown large enough in time to accommodate the influx of new data.
Some customers run hosting environments and deploy rather generic virtual machines then protect them with DPM. Sometime in the future the owners of those VM’s deploy applications that create data (like exchange) or load new data into the guests. This large increase in the VM size can cause ongoing DPM backup failures if the replica cannot be grown large enough in time.
File Server protection.
DPM Supports protecting Windows dedup volumes. DPM will store the protected file data in a dedup state when the entire volume is protected. If at a later time you decide to only protect a subset of data – or if you stop dedup on the protected server, DPM will start protecting the volume in a non-dedup state. This will require much more space on the DPM replica to hold the file data in its native non-dedup form.
Below is an example of a failed recovery point job for a VM due to an undersized replica.
Type: Recovery point
Description: DPM is out of disk space for the replica. (ID 58 Details: There is not enough space on the disk (0x80070070))
End time: 3/22/2017 12:04:21 PM
Start time: 3/22/2017 11:30:01 AM
Time elapsed: 00:34:20
Data transferred: 22,260.38 MB
Cluster node -
Recovery Point Type Express Full
Source details: DPM2016-GA
Protection group: Hyper-V
As in previous versions, DPM 2016 has replica auto-grow feature for modern backup storage (MBS) to help increase the replica sizes as the data sources grows. Under normal use conditions this feature works perfectly fine. If a job fails due to out of disk space, it will automatically grow the replica volume and schedule a new synchronization or recovery point job to run one hour in the future. However, if the amount of new data is much larger than the size of the replica after auto-grow, the jobs will continue to fail even as the auto-grow continues to increase the replica size. After two failures, auto-rerun is no longer triggered by default. In DPM 2012 R2 you had the ability to manually grow the replica volume as large as you wanted by using the “modify disk allocation” wizard, however in the DPM 2016 you do not have the ability to manually grow the replica volume using the same wizard. This can cause delays in getting good backups again to meet your SLA. If you know the new size of the protected data or want to grow the replica volume for future data growth in order to prevent future backup failures, you can grow the replica manually outside of DPM.
Manually Extending a Replica volume on MBS
DPM 2016 Update Rollup 1 added support for using the DPM PowerShell cmdlet
to extend a DPM Replica volume hosted on Microsoft Modern Storage.
The below DPM PowerShell script helps simplify the process of manually extending a replica volume regardless if it is located on legacy LDM disk based or Modern Backup Storage (MBS) volumes.
DPM PowerShell script
Copy below and save as ResizeReplica.ps1 then run it from the DPM PowerShell console.
#Resized Replica Volume located on DPM 2016 +UR1 Modern Backup Storage.