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