none
Recovery Points frequently fail RRS feed

  • Question

  • I'm currently running DPM 2010 (3.0.7707.0) on Win2008 R2 SP1. I'm finding that recovery points for file protection are frequently failing to be created. If I try to create the recovery point manually, it immediately fails again. The only way I can get the recovery point to be created is to restart the machine, or to choose the option to sync, then create a recovery point. I've tried to look through the logs, but find them to be pretty cryptic. From what I can tell, though, DPM is not able to access the last sync point when it goes to create the recovery point. That's why I have to do a sync, then create to get a recovery point made. It seems like something is happening to the sync points. Sometimes, recovery points will work fine for days, but then they'll start failing non-stop until I restart the machine. I currently have 3 protection groups. The one where this problem occurs most often is one where I have 15-minute sync setup. The others have the problem occasionally, but nowhere near as often, and they use 1-hour and 2-hour sync settings. One idea I had was that SiS could be active, and could be moving the sync points around, but that does not seem to be the case. Any ideas?
    Wednesday, August 24, 2011 3:58 PM

Answers

  • I did end up finding a fix, but I'm still not sure what the real issue was. The problem WAS that the synchronizations were failing to run. So, when it would go to create a recovery point, there was no new data, so the recovery point couldn't be made. Unfortunately, it was hard to track this down. Instead of the scheduled syncs getting marked as failed, they just disappeared from the system entirely. I believe that is a bug with DPM. It also would help if the Recovery Point error mentioned that there were no available sync points, or something similar.

    Digging into SQL a bit, I found that it was throwing up an error about not being able to delete some tasks. What I ended up doing was setting the DPM services to run using the Local System account, and that fixed the problem, but I'm not sure why. This is the second DPM system I've setup (though the last one was the 2007 version), and all permissions for the DPM Account that DPM creates seem to be the same between the two systems. If I remember correctly, DPM creates it's special user account, so I'm not sure what could have gone wrong when it was configuring permissions.
    • Edited by spyd3r0x Friday, October 7, 2011 2:09 AM
    • Marked as answer by spyd3r0x Friday, December 30, 2011 5:19 AM
    Friday, October 7, 2011 2:07 AM

All replies

  • Maybe you are exceeding the maximum number of recovery points.

    What kind of group that are syncing every 15 minutes? are you protecting exchange or sql? or just files?

    Check the KB below and make sure that you are not exceeding the limits

    http://technet.microsoft.com/en-us/library/ff399518.aspx

     

    Deleting old recovery points and changing the sync to 2 hours (if you are having the problem of limitation) might solve the problem. its all down to calculation.

     

    Hope that helps.

    Laith.

    Wednesday, October 5, 2011 7:03 PM
  • Hi,

    If your synchronizations are failing to run, that will cause the recovery point job to fail because we can't take two snapshots of a volume that has not had any changes done to it in between.  You can simulate this by creating three recovery points in this order.

    A) Select the option to "Only synchronize (available only for file data)
    B) Select the option to "create recovery point without synchronizing" - the fist one will succeed
    C) Select the option to "create recovery point without synchronizing" - the second one will fail immedietly

    So look at the job history and see if any synchronizations ran and suceeded between recovery point times.

     


    Regards, Mike J. [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.
    Wednesday, October 5, 2011 10:42 PM
    Moderator
  • I did end up finding a fix, but I'm still not sure what the real issue was. The problem WAS that the synchronizations were failing to run. So, when it would go to create a recovery point, there was no new data, so the recovery point couldn't be made. Unfortunately, it was hard to track this down. Instead of the scheduled syncs getting marked as failed, they just disappeared from the system entirely. I believe that is a bug with DPM. It also would help if the Recovery Point error mentioned that there were no available sync points, or something similar.

    Digging into SQL a bit, I found that it was throwing up an error about not being able to delete some tasks. What I ended up doing was setting the DPM services to run using the Local System account, and that fixed the problem, but I'm not sure why. This is the second DPM system I've setup (though the last one was the 2007 version), and all permissions for the DPM Account that DPM creates seem to be the same between the two systems. If I remember correctly, DPM creates it's special user account, so I'm not sure what could have gone wrong when it was configuring permissions.
    • Edited by spyd3r0x Friday, October 7, 2011 2:09 AM
    • Marked as answer by spyd3r0x Friday, December 30, 2011 5:19 AM
    Friday, October 7, 2011 2:07 AM
  • By default the DPM service accounts run under the local system context - had you changed these after the installation of DPM?

    From what I understand when DPM is synchronising file data from the protected server it will use the DPMRA service to complete that function and write the data to the replica volume. If the account the service is running under does not have the permissions to modify the data on that replica volume then the sync would fail - but I can't explain why you would be seeing a failure in the management console unless the DPM local system accounts did not have permissions to SQL to write the error(?). Similarly, the DPM Writer is the service that would manage the snapshot to create the recovery point, once sync is completed.

    The two local accounts created by the DPM installer, DPMR$DPMServername and Microsoft$DPM$Acct are used for accessing and reporting on information in the DPM Database.

    Hope this helps.

    Friday, October 7, 2011 4:22 AM