Understanding DPM 2016 Replica and Backup Storage

Understanding DPM 2016 Replica and Backup Storage.

• 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 the BMR data source but assumes 20 GB for all servers. At the time of protection, this cannot be changed on 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 affects all future BMR replica allocation sizes.

The size of the 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. Alternatively, 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
REG_DWORD: ReplicaSizeInGBForSystemProtectionWithBMR

Cu toate acestea, 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).

• Exchange Protection. 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.
• Hyper-V Protection. Some customers run hosting environments and deploy rather generic virtual machines and then protect them with DPM. Sometime in the future, the owners of those VMs 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
Status:  Failed
Description:        DPM is out of disk space for the replica. (ID 58 Details: There is not enough space on the disk (0x80070070))
More information
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 a replica auto-grow feature for modern backup storage (MBS) to help increase the replica sizes as the data sources grow. Under normal use conditions, this feature works perfectly fine. If a job fails due to an 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 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.