DPM and System State Backup Explained

Chris Butcher | Senior Support Escalation Engineer

Hello again folks, this is Chris Butcher and I realized it has been too long since my last blog post. I recently worked with a customer and through our conversations realized that there is a lack of information out there on how System Center 2012 Data Protection Manager (DPM) protection for System State and Bare Metal Recovery (BMR) works. While it is a short read, it seemed like a good opportunity to be sure the information is out there.

So, as we were talking about the specifics of a system state backup, I found that the documentation wasn’t quite as thorough as it should be. This will focus primarily on that piece (system state) mainly because the BMR piece is pretty basic and doesn’t need too much attention.

The process for both will be focused on Windows 2008 and forward. This is when DPM began leveraging the new Windows Server Backup (WSB) feature as NTBackup had been deprecated.

What happens when a system state backup is taken against a protected server? Well, the first thing DPM does is communicate with WSB to request a backup of the server’s system state. While this seems basic, there are some other items to be considered during this process. Behind the scenes, DPM and WSB made a determination when the agent was installed as to which drive it would use. This by default is the drive with the most available free space. That information gets saved into the PSDataSourceConfig.XML file (which we will talk about later). This is the drive WSB will use to do backups to.

WARNING: While this seems like a pretty simple calculation that will likely not affect you, there is one caveat here to be aware of. If the server you are protection is a member of a cluster, it is possible that a cluster drive will be selected in this process. If that drive ownership has been switched to another node, then next time system state for the node is done, the drive is no longer available and the backup will fail. In this situation, you will need to modify the PSDataSourceConfig.XML to point it to a local drive. This process is detailed later.

WSB will then create a folder on the root of that drive called WindowsImageBackup. As it creates the backup, all of the data will be put there. Upon completion of the backup, the file will then be transferred over to the DPM server.

As shown here, you can see that my DPM server shows a backup done at 10:23PM.

On the computer I am protecting (in this case cbutch782), you will find the WindowsImageBackup folder on my C: drive with a creation date/time that matches.

This is where there may be confusion. The following two points aren’t common knowledge:

1. This folder and its contents do not get cleaned up after the backup or transfer is done. The best way to think of this is that the space is being reserved for the next time a backup is done.

2. The folder gets created every time a backup is done. The time/date stamp will reflect the time of your last system state backup.

How does this differ from a BMR backup? Well, with BMR (which inherently captures a system state as part of the process), the backup job will be done directly to a share on the DPM server. What happens is that the DPM server shares out the replica volume for that BMR backup and when it calls WSB, it just tells it to not use the drive with the most free space, but instead use the share that it has created for this job.

So, you are probably asking yourself how you can change this behavior. You may not want DPM to use a given drive for the system state backup. Well, you are in luck. There is a way to tell DPM which drive to use.

1. On the server you are backing up, navigate to C:\Program Files\Microsoft Data Protection Manager\DPM\Datasources.

2. There you will find a file named PSDataSourceConfig.XML. Right click that file and choose to edit.

3. Find the section for <FilesToProtect> which is followed by a drive letter and WindowsImageBackup. This will be the current location WSB will put the files.

4. Modify the file to reflect the drive letter you want WSB to use. In my case, I changed it to use my E: drive.

5. Once this is done, close and save the file.

6. Go back to the DPM server and run a consistency check against the System State data source.

You can see that after running that in my case, I now have a new folder on my E: drive with the time/date that matches the consistency check (which of course also creates a recovery point).

And on the DPM server, we see the same time and date as the WindowsImageBackup folder.

Well, that’s about it for system state backups. As I said, it is primarily informational to allow our users to better understand the process and hopefully not be too surprised when the find a random folder somewhere on their protected computer. Fear not, it is expected!

Here are some other blog posts and troubleshooting steps you can walk through that deal with system state and BMR backups.

BLOG POSTS:

· http://blogs.technet.com/b/filecab/archive/2009/05/04/deciding-between-system-state-backup-and-allcritical-backup-in-windows-server-2008.aspx

· http://blogs.technet.com/b/dpm/archive/2011/10/31/troubleshooting-data-protection-manager-system-state-and-bare-metal-backup.aspx

· http://blogs.technet.com/b/dpm/archive/2010/05/12/performing-a-bare-metal-restore-with-dpm-2010.aspx

TechNet: Troubleshoot VSS issues which occur with Windows Server Backup (WBADMIN) on Windows Server 2008 and Server 2008 R2:

http://technet.microsoft.com/en-us/library/ee692290(WS.10).aspx

Chris Butcher | Senior Support Escalation Engineer | Microsoft GBS Management and Security Division

Get the latest System Center news on Facebook and Twitter:

System Center All Up: http://blogs.technet.com/b/systemcenter/
System Center – Configuration Manager Support Team blog: http://blogs.technet.com/configurationmgr/
System Center – Data Protection Manager Team blog: http://blogs.technet.com/dpm/
System Center – Orchestrator Support Team blog: http://blogs.technet.com/b/orchestrator/
System Center – Operations Manager Team blog: http://blogs.technet.com/momteam/
System Center – Service Manager Team blog: http://blogs.technet.com/b/servicemanager
System Center – Virtual Machine Manager Team blog: http://blogs.technet.com/scvmm

Windows Intune: http://blogs.technet.com/b/windowsintune/
WSUS Support Team blog: http://blogs.technet.com/sus/
The AD RMS blog: http://blogs.technet.com/b/rmssupp/

The Forefront Endpoint Protection blog : http://blogs.technet.com/b/clientsecurity/
The Forefront Identity Manager blog : http://blogs.msdn.com/b/ms-identity-support/
The Forefront TMG blog: http://blogs.technet.com/b/isablog/
The Forefront UAG blog: http://blogs.technet.com/b/edgeaccessblog/