My Old IIS.NET BlogTechNet Magazine Articles Learn about IIS7 from a book I wrote a few years back!
I recently had a couple of servers where they had rather small system partitions, one was Windows 2003 while the other was Windows 2008 RTM and DPM continued to fail with replica is inconsistent errors. The DPM documentation and event errors were referencing the replica and volume partition size(s) and all checked out with plenty of space according to the current data size.
As a test, I thought about checking the actual system partition size on the protected servers and noticed small free space available on these virtual machines.
For testing purposes, I shut the virtual machine and expanded the system partition virtual hard disk. To do this, I simply did the following:
After the volume free space is sufficient (greater than 30+ gigabytes was my goal), then I re-run the consistency check for the replica partition for the server(s) that failed.
To re-check the consistency check, you do the following:
The one problem that many might run into is the system partition isn’t expandable using the “extend volume” as it is either not supported (Windows Server 2003) or is a physical disk limitation. In either case, the choice at this point is less related to creating the relevant space in order to successfully get system state backups to succeed and more pointed at moving the system state backup to another location.
NOTE: If you have limited space for your system partition and no other volume with significant space available to host the backup, you have bigger problems than the replica backup failing. You should fix the limited free space first for this server and then focus on the following fix.
As I wasn’t familiar with how to successfully re-locate system state backup location, I used Bing search to see if others had figured this out already. I came across this small blog post that was very helpful and for the most part was completely accurate thought I did have to make one minor tweak to finally get things happy (e.g. no failures or errors, just the big old Green OK check mark).
Follow these steps outlined in the post above -
As mentioned in the blog post above, DPM’s protection group will now go south on you and it will seem permament. This is expected since the location of the system state configuration has changed. The protection group needs to be modified through the wizard and as mentioned it should do so with no changes. This, unfortunately, didn’t do the case every time and some protection groups were still failing. This was easily determined using the DPM Events in the event viewer for the server with the following:
“DPM has detected changes in the file locations or volume configurations of protected objects…”
In order to correct this failure, I had to use the modify protection group wizard and remove the System State from the protected server and add it back. After doing this, the replica consistency started working as planned.
In the short time I’ve started using DPM 2007, I’ve found it to be rather straight forward to troubleshoot failures with replica backups. The issue is usually related to volume space not large enough, in my experience thus far. With some quick cleanup, you can easily turn things around assuming you have the disk space (got to love SAN’s and DAS!) and the DPM console.
Hope this helps,
-Chris
"I had to use the modify protection group wizard and remove the System State from the protected server and add it back."
That helped us update the Replica Path for some SQL databases when we moved them to another drive.
Thanks!
Hey Michael-
Very cool! I'm kinda new to DPM and I recently updated to DPM 2010 beta and it has run like a champion! I'm not sure if you've started playing with it yet but it seems to fix all the "issues" that occur during runtime.
Nonetheless, I've fixed problems before by doing exactly what you mentioned as well. Good tip for newbies for sure...
Thanks,