Saturday, August 11, 2012

DPM 2012 BMR Errors when trying to restore


So I thought this was interesting…

Microsoft System Center DPM uses Windows built in backup to create a Bare Metal Recovery file for use with the windows disk if you want to restore from scratch.  I know that the windows backup just creates a new file (once upon a time it was .bak).  Well, I decided to do a test restore of a system with DPM 2012… Step one restore that windows backup to a share or volume… FAILED!  The simplest step was failing for me.  Well, a few calls to Microsoft and I got it resolved, but let’s look at what happened.

The DPM Remote Agent installs on a client server and decides a few things on its own.  One of those things is where to store the BMR files.  Specifically it finds the largest drive and creates a hidden folder X:\WindowsImageBackup and updates PSDataSourceConfig.xml to reflect this.  DPM cannot tell if this drive is a cluster drive, a iSCSI drive, or anything else.  If it is the biggest when you install it is chosen.

As a result of this, every guide out there will tell you to check PSDataSourceConfig.xml and point it to a stable local drive.  This is even a step in troubleshooting from a Microsoft Blog. 

Here is the problem, even if changing this makes your backups work, your BMR will fail when you try to pull it out.  The DPM server creates a partition with something along the lines of F-vol in it (where F is a drive letter).  This is done when you setup BMR on the server from the DPM Console.  The DPM server will not update or change this if you change it on the client side!  The recovery pointer in the database will look for C-vol and you will get a nice:



The recovery jobs for System Protection Computer\System Protection that started #####, with the destination of #######, have completed. Most or all jobs failed to recover the requested data. (ID 3111) DPM encountered an error while performing an operation for C:\WindowsImageBackup\ on ######### (ID 2033 Details: The system cannot find the path specified (0x80070003)).



So DPM will back up to one folder and try to restore from one that does not exist.  Sucks…



The solution is to either put the BMR back on that other drive by editing PSDataSourceConfig.xml, or rip out all protection of that server and start over.  And this time edit PSDataSourceConfig.xml before you connect the client to the DPM server… Sucks more.

No comments:

Post a Comment