none
Clarification please on what "DPM could not find a valid recovery point" means. RRS feed

  • Question

  • Ok, Ive been adjusting replica and recovery point sizes, doing re-syncs, and creating recovery points all morning. 

    Syncing works fine. I have recovery points for today. As far as i can tell, the sync and recovery points worked just fine at noon, but the tape failed because it couldn't find valid recovery points.

    What constitutes a valid recovery point?

    It looks like the Recovery Point Status report figures they are valid if the recovery point was created and copied to tape in the last 24 hours or so. Actually, it says "in the specified recovery point window". I haven't seen where that is set or defined yet,

    How do I make sure my last recovery points actually get written to tape?

    Is there a possibility that if a recovery point is already written to tape, trying to write it tape again constitutes an error?

    What if I just want to copy whatever recovery points I have on the machine to another, single tape?

    Thanks,

    Bob.

    Wednesday, May 4, 2011 5:58 PM

Answers

  • Hi Bob,

    I think you are over complicating the problem.  As long as scheduled disk synchronizations and recovery points are succeeding, then the tape backups will take of them selves and also succeed.  You don't need to force changes to data sources for a new scheduled disk based recovery point to be created.  You need to troubleshoot why the synchronization, consistency check, or recovery point jobs failed and fix that problem.

    See error 30126 on http://technet.microsoft.com/en-us/library/ff399290.aspx

    Unlike disk based recovery points, Recovery points on tape expire on an absolute date, regardless if you have a recent backup on tape or not.  You can use the recovery point status report to check the health of your tape backups and take appropriate action if a tape job fails. You can use the tape management report to see what tapes are due back for reuse - that is based on tapes being expired.


    Regards, Mike J. [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.
    Thursday, May 5, 2011 3:27 PM
    Moderator

All replies

  • Hi,

    <snip>
    Is there a possibility that if a recovery point is already written to tape, trying to write it tape again constitutes an error?
    >snip<

    Correct, DPM scheduled backups will not write the same recovery point to tape twice. However, ad-hoc tape backups allow you to write multiple RP's to the same tape as many times as you like.

    <snip>
    What if I just want to copy whatever recovery points I have on the machine to another, single tape?
    >snip<

    Under the recovery tab, restore a data source and chose the option to "Copy to tape" - that will restore the data to a tape for you to take offsite or restore from another DP server.


    Regards, Mike J. [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.
    Wednesday, May 4, 2011 11:23 PM
    Moderator
  • Mike, interesting.

    Um, does this mean if a protected source is not modified since the last recovery point, it will not be on the next tape? Does this mean I or my customer can not count on all of the customer's data to be on the single tape that they take offsite each day?

    What about month-end tapes?

    What about year-end tapes?

    When we do a restore, especially if the server crashes completely and we're on a new machine, and one of the tapes is unreadable, and we have to load something that is totally out of sync with the other tapes, does this mean we have to manually figure out the dates and times on each tape to figure out which to restore?

    Why is it called a failure? Why isn't it called "We didn't bother to copy to tape because its on another tape somewhere?" 

    How do I get it to NOT fail, to ALWAYS trigger a recovery point? It's pretty dumb to have to now allocate a whole bunch of extra disk space, start a restore of a few hundred gigs, wait, then backup it up, then presumably delete the restore (unless you're suggesting overwriting the primary arrays), AND pay someone to do all this manually. Is it me or am I missing something? (And OH! how do we know before hand that a protected item would have to be restored as there is absolutely no sign of any problem until the tape job is nearly complete? - That implies we would now have to restore the whole kit and caboodle as the rest of the stuff is on tape - oh and how about if some user decides to work late one evening in the middle of all this?)

    Sorry, another one. If we have a volume that changes extremely rarely, say once in six months, but has critical stuff on it, how often does it get written if the tape rotation is only five days? Do we have to keep a manual copy of a tape after its expiry period?

    Thanks,
    Bob.




    Thursday, May 5, 2011 12:51 AM
  • Mike,

    I spent several hours last night creating recovery points for each protected item and reviewing other threads concerning this topic.

    First the good news. I manually triggered the creation of a recovery point for each recovery item. I confirmed they were all created in the Recovery | Browse Tab with a date and time that was after than my last tape backup time. All these items now show up in the last tape backup, and I now have a tape with all my recovery items on it.

    Bad news. This means a full consistency check has to be performed on the Hyper-V items, which takes hours. Plus , this has to be done manually.

    So, questions again:

    1. As long as even one minor change happens within a protected item, then it should create a new shadow copy / recovery point correct? That means if I create a scheduled task to xcopy in and overwrite an empty, dummy file to the root of each protected partition, then I will have a date change which will create a whole new recovery point right? And as long as that is done after the last tape backup and before the last scheduled DPM recovery point creation, the recovery point will be copied to tape in its entirety right?

    2. What about Hyper-V VHDs? If I had a dormant VM with multiple VHDs, and I xcopied that dummy file into just one of the VM's VHDs, the entire VHD gets written to tape right? (Not that I know how to do this one yet though.)

    3. How does one reliably force a change to System Protection on the DPM Server? Is there any file or folder that can be touched safely or is it always modified, hence always has new recovery points?

    4. What about the Initial Store? How can I force the Initial Store to create a recovery point automatically?

    5. What about the DPM Database? I currently have DPMDB, master, model, msdb, ReportServer$MSDPM2010 and ReportServer$MSDPM2010TempDB being protected. Do I need all of these for a restore? It looks like "model" has a new recovery point created every 15 minutes, but not the other items. How can I ensure that all items I need for a single tape restore get modified so new recovery points are created so they get written to tape?

     

    Now, about the other threads. There seems to be a class of issue in which old tapes that should be expired are not being expired. Would this be because the old tape has a recovery point that has not been changed since that tape was created, so that a more recent recovery point was never written to a more current tape, and DPM is "smart" enough to know that those really old tapes can't be expired because they are the only backup tapes that actually have a backup of an unchanged protected item?

     

    Sorry about all the questions here Mike, but I think that grasping an accurate understanding of this whole ID 30126 issue and the way DPM manages recovery points can have important operational implications that could mean the difference between recovering a customer's data correctly, and quickly, or not. I mean, DPM officially treats 30126 as an error and I have not been able to find any satisfactory documentation so far on what procedures to put into place. If customers' data is lost, who is legally liable here? Me for not dealing with the error in an effective way, or Microsoft for not having documentation and mechanisms in place?. If you are unable to answer any of these questions definitively, could you pass them on to the development team somehow?

    Thanks again,
    Bob.


    Thursday, May 5, 2011 10:08 AM
  • Hi Bob,

    I think you are over complicating the problem.  As long as scheduled disk synchronizations and recovery points are succeeding, then the tape backups will take of them selves and also succeed.  You don't need to force changes to data sources for a new scheduled disk based recovery point to be created.  You need to troubleshoot why the synchronization, consistency check, or recovery point jobs failed and fix that problem.

    See error 30126 on http://technet.microsoft.com/en-us/library/ff399290.aspx

    Unlike disk based recovery points, Recovery points on tape expire on an absolute date, regardless if you have a recent backup on tape or not.  You can use the recovery point status report to check the health of your tape backups and take appropriate action if a tape job fails. You can use the tape management report to see what tapes are due back for reuse - that is based on tapes being expired.


    Regards, Mike J. [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.
    Thursday, May 5, 2011 3:27 PM
    Moderator
  • Mike,

    It looks like all of my Recovery Points were copied OK to last night's tape on their own. My problem might have arisen from attempting multiple tape backups in a single day before all Recovery Points were created.

    Thanks,
    Bob. 

    Friday, May 6, 2011 7:49 PM
  • Gr8 Bob, glad it's explainable and that everything is working smoothly for you now.
    Regards, Mike J. [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.
    Friday, May 6, 2011 8:27 PM
    Moderator