Replica is inconsistent error
The first error that I want to talk about is the infamous "replica is inconsistent" error, shown in Figure A below (click on image for full size). A replica is inconsistent error occurs when the blocks that have been backed up do not match the current state of the protected resource.
This error message means that for some reason the replica stored on the DPM 2007 server has fallen out of synchronization with the protected data set. Although you can still restore previously created restore points, the protected data set will not be backed up again until you fix the error.
Figure A: Replica is inconsistent error
Replica is Inconsistent is the most common Data Protection Manager 2007 error.
The methods for dealing with this error vary, depending on whether the error occurs during the initial synchronization process, or after the data has already been protected.
The initial synchronization process in Data Protection Manager
It is very common for DPM 2007 to report a replica as inconsistent for one or more protected resources just after the initial synchronization process.
The first thing that I recommend doing is comparing the DPM 2007 server's clock to the clocks on the servers that you are trying to protect. If the clocks are out of synch, it can cause replication to fail (although usually you won't even be able to deploy a protection agent if the clocks are out of synch).
Once you have verified that the clocks are in synch, right click on one of the inconsistent replicas, and select the option to perform a consistency check, as shown in Figure B below (click on image for full size). During the initial synchronization, DPM often tries to synchronize multiple protected resources simultaneously. I have found that performing a consistency check on one inconsistent replica at a time usually yields better results than trying to synchronize everything at the same time. In the case of an initial synchronization, this almost always works. The next paragraph discusses other things that you can try if it doesn't work.
Figure B: Initial synchronization process in DPM 2007
Try performing a consistency check on inconsistent replicas.
Finally, if you're having trouble with getting a protected server's system state to synchronize, make sure Windows Server Backup is installed on that server. Although DPM 2007 is designed to be a standalone product, it depends on Windows Server Backup for making system-state backups of protected Windows 2008 servers.
Other causes of the inconsistent replica problem are fairly obscure. Things like network problems, delayed write failures, and disk controller errors can also cause a synchronization to fail, but those are hardware issues rather than problems with DPM 2007 or with the protected data set.
Random inconsistent replicas
It is also common for replicas to randomly become inconsistent. When this happens, you can usually fix the problem by performing a consistency check. Again, it usually works best to perform the consistency check on one inconsistent replica at a time.
If the consistency check continues to fail, then verify that the protected server isn't currently juggling a heavy workload. Someone at Microsoft once told me that a consistency check will fail if the protected server has to perform a virtual memory paging operation during the check. The best way to prevent this from happening is to make sure that your protected servers have plenty of memory installed.
To see if installing more memory fixes the problem, you can monitor the Process/Page File Bytes counter in the Performance Monitor. If this value changes, it shows that Windows is dumping memory contents to virtual memory.
Recovery point creation failed
Another common DPM 2007 error that I want to talk about is the Recovery Point Creation error, as shown in Figure C below (click on image for full size). Although DPM 2007 performs synchronizations throughout the day, it usually only creates three recovery points per day. Recovery points are points in time that you can restore the server to.
Figure C: The Recovery Point Creation error
Because there are only a limited number of recovery points each day, it is important to make sure that DPM 2007 doesn't fail to create them.
Most of the time, you can fix this problem by right clicking on the failed replica and choosing the "Create Recovery Point" option from the shortcut menu. Upon doing so, Windows will display a "Create Recovery Point" dialog box similar to the one shown in Figure D below (click on image for full size). Choose the option to create a recovery point by using an express full backup.
Figure D: Creating a recovery point
Choose the option to create a recovery point by using an express full backup and click OK.
If you are not able to manually create a recovery point, then you need to find out why. If you look back at Figure C, you will notice that the bottom of the screen displays status information for the protected resource. In some cases, this area will provide you with a reason for the failure.
Another common cause of recovery point creation failures is exceeding the maximum number of recovery points. When this occurs, the status area will display error number 130, along with the following text:
You cannot add more recovery points because the maximum number of recovery points for the entire retention range is
When this occurs, you must decrease the retention time or decrease the number of days per week that you are making backups.
Although synchronization and recovery point errors are common within DPM 2007, it is important to remember that there is usually a logical cause for these errors. By tracking down the root cause, you can eliminate the error and protect your data.
About the author: Brien M. Posey, MCSE, has previously received Microsoft's MVP award for Exchange Server, Windows Server and Internet Information Server (IIS). Brien has served as CIO for a nationwide chain of hospitals and was once responsible for the Department of Information Management at Fort Knox. You can visit Brien's personal website at www.brienposey.com.
This was first published in March 2010