none
Recovery Point creation fails because change traking has been marked inconsistent RRS feed

  • Question

  • I have a Hyper-v Cluster that is backed up using DPM 2012 SP1, for the last week when recovery point creation attempts to run I receive the following error message.

    Change Tracking has been marked inconsistent due to one of the following reasons
    1. Unexpected shutdown of the protected server
    2. Unforeseen issue in DPM Bitmap failover during cluster failover of one or more datasources sharing the tracked volume. (ID 30501 Details: The parameter is incorrect (0x80070057))

    After this error it performs a consistency check, it completes and a backup is stored, but as soon as it does another recovery point creation it fails again with the same error.

    I have a Server 2012 R2 Hyper-v cluster with 2 virtual hosts and a quorum disk acting as the deciding vote. The backups completed for a month prior to this with no problems. No event seems to have triggered this problem it is just completely out of the blue.

    I have update roll-up 8 on DPM and have both hosts within the cluster updated. They seem to consistently fail on one virtual host and intermittently fail on the other virtual host.

    The event logs do not have any errors other than Event ID 1 VDS basic provider

    Wednesday, January 21, 2015 4:07 PM

Answers

  • Hi,

    Lets see if cleaning up all the filter bitmaps clears up the problem.

    To get to a clean state please delete DpmFilter* files from “System Volume Information” using following steps.

    1. Open an administrative command prompt and run:
           C:\>fltmc unload DpmFilter (run on all cluster nodes)
    2) From one of the Cluster nodes, run:
           C:\>psexec -s cmd  (psexec is www.sysinternals.com tool used to run cmd under system account)
    3) In this new command prompt (running as system) run:
           C:\>CD C:\ClusterStorage
           C:\ClusterStorage>For /d %i in (volume*) do del /s "%i\System Volume Information\DpmFilter*"
          
    Note: The * includes (DPMFilterBitmap{Guid}, DPMFilterStatus, DPMFilterLog, DPMFilterTrace*)

    4) verify files are deleted by running
            “dir /s /b DpmFilter*”
            exit
           
    5) Then load the filter again on all nodes
           C:\>fltmc load DpmFilter (on all cluster nodes)
          
    6) Run DPM Consistency check against all the VM's to re-start normal protection.


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. Regards, Mike J. [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.

    Friday, January 23, 2015 3:41 PM
    Moderator

All replies

  • Hi,

    Lets see if cleaning up all the filter bitmaps clears up the problem.

    To get to a clean state please delete DpmFilter* files from “System Volume Information” using following steps.

    1. Open an administrative command prompt and run:
           C:\>fltmc unload DpmFilter (run on all cluster nodes)
    2) From one of the Cluster nodes, run:
           C:\>psexec -s cmd  (psexec is www.sysinternals.com tool used to run cmd under system account)
    3) In this new command prompt (running as system) run:
           C:\>CD C:\ClusterStorage
           C:\ClusterStorage>For /d %i in (volume*) do del /s "%i\System Volume Information\DpmFilter*"
          
    Note: The * includes (DPMFilterBitmap{Guid}, DPMFilterStatus, DPMFilterLog, DPMFilterTrace*)

    4) verify files are deleted by running
            “dir /s /b DpmFilter*”
            exit
           
    5) Then load the filter again on all nodes
           C:\>fltmc load DpmFilter (on all cluster nodes)
          
    6) Run DPM Consistency check against all the VM's to re-start normal protection.


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. Regards, Mike J. [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.

    Friday, January 23, 2015 3:41 PM
    Moderator
  • This seems to have done the tricks, 3 days of backups without any issues.

    Thank you very much.

    Monday, January 26, 2015 12:51 PM
  • This seems to be reoccurring again, is this normal?
    Tuesday, February 17, 2015 1:57 PM
  • Hi,

    No - that is not normal - what leads up to the re-occurrence, any node crashes, storage related problems etc.

     


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. Regards, Mike J. [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.

    Tuesday, February 17, 2015 4:41 PM
    Moderator
  • No changes have been made to the cluster, there has not been any hardware failures or crashes of VM hosts. The Storage is an HP lefthand SAN and it does not have any errors. We do occasionally get a cluster event 5120 followed by a 5127 error, it occurs when a backup job starts but its not every time and it does not always happen with the same backup job.
    Tuesday, February 17, 2015 4:50 PM
  • Also by moving the effected guest to another node in the cluster the problem goes away.
    Thursday, February 19, 2015 1:19 PM