none
Green OK and no alerts for failed job "A journal wrap error has occurred on the change journal," RRS feed

  • Question

  • Hi,

     

    We check the health of the system looking for Active alerts and then go to the Protection groups and make sure they have green ticks.

     

    I’ve been having an issue with a DPM backup of my profile store but it doesn’t generate an alert and when you view the protected resource it’s listed as a green tick. I reload the console but I still have a green tick and no active alert.

     

    I have created a job filter for the protected resource and find the job and it lists the job as failed with 0 MB data transferred. The error message is ..

     

    A journal wrap error has occurred on the change journal, and therefore DPM is unable to track any more changes or may have missed some changes for the data source C:\Data\Profiles on FS1.wiltshire.ac.uk (ID 30117 Details: Internal error code: 0x809909D1)

     

    I’m in the process of creating a larger journal to resolve the issue.

     

    I’m running DPM 2010, the protection group is set to 7 days, synchronization before a recovery point. Currently latest recovery point is showing as 25/02/2011 and has a “green ok” were as all other servers in that protection group have a last recovery point of 04/03/2010

     

    My concern is that no alert is generated and the resource reports as protected even though it is outside of the protection group’s short term recovery window. What else might be failing that I’m not receiving alerts for?

     

    Is this some kind of “by design” behaviour?

     

    Any help much appreciated.

    J

    Friday, March 11, 2011 3:12 PM

Answers

  • Hi,

    Ok - there are two aspects of this problem.

    1) Synchronization is failing due to USN journal wrap.
           Solution: Increase synchronization frequency or increase the USN Journal on the protected server.
    2) As a result of a failed synchronization, the volume is inconsistent and the recovery point is not made.
           Solution: Ths is by design behavior. There is no explicit corrective action for RP failure when replica in inconsistent. Next scheduled RP will succeed. SLA report will indicate this though. 

     


    Regards, Mike J. [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.
    Thursday, December 15, 2011 4:02 PM
    Moderator

All replies

  • HI,

    The above failed job should have triggered an automatic consistency check if that PG is currently configured to do so.  Please look at your custom filter for that data source and make sure you are selecting all job types, then look at all jobs that occured leading up to and after the failed job.   Also look at inactive alerts.


    Regards, Mike J. [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.
    Saturday, March 12, 2011 2:39 PM
    Moderator
  • Hi,


    Sorry for the late reply.

    I’ve checked and the Protection Group in question and it’s configured to have a short term retention policy of 7 days and sync just before a recovery point. File RP’s should occur every Fri @ 20:00 to disk and then 23:00 to tape for long term protection. The Consistency check option “Run a consistency check if a replia becomes inconsistent” is enabled.

    After looking at the jobs for 25/03/2011 (sorry UK date format) here are my findings,

    • A failed CC started at 20:06:41 and took 00:00:18 and transferred 0MB
    • A filed CC started at 20:07:00 and took 00:00:00 and transferred –


    The error description is “A journal wrap error has occurred on the change journal, and therefore DPM is unable to track any more changes or may have missed some changes for the data source C:\Data\Profiles on MYSERVER.MYDomain.COM (ID 30117 Details: Internal error code: 0x809909D1)”

    • A successful CC started at 20:22:02 and took 07:36:52 and transferred 16,159.29 MB


    After looking at the inactive alerts for the same date only event for this server are

    • Replica inconsistent, verification in progress

    The replica for Volume C:\Data\Profiles is currently being synchronized with consistency check. A consistency check can be started automatically or manually. To configure automatic consistency check options, modify this protection group using the Modify Protection Group Wizard. To start a manual consistency check, click Perform Consistency Check from the Actions pane on the Protection tab. (ID 3104)


    So there are no alerts or jobs for relating to a recovery point for this protected resource. Is the failure of the CC stopping the RP from being scheduled and therefore doesn’t generate a failure alert?

    Thanks,

    J

     

    Thursday, March 31, 2011 11:40 AM
  • This same exact scenario just happened to me today. Would love to hear an answer.
    Thursday, December 15, 2011 3:45 PM
  • Hi,

    Ok - there are two aspects of this problem.

    1) Synchronization is failing due to USN journal wrap.
           Solution: Increase synchronization frequency or increase the USN Journal on the protected server.
    2) As a result of a failed synchronization, the volume is inconsistent and the recovery point is not made.
           Solution: Ths is by design behavior. There is no explicit corrective action for RP failure when replica in inconsistent. Next scheduled RP will succeed. SLA report will indicate this though. 

     


    Regards, Mike J. [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.
    Thursday, December 15, 2011 4:02 PM
    Moderator
  • Mike's suggestion is right. After I increased USN journal (

    http://technet.microsoft.com/en-us/library/cc788042(v=ws.10).aspx

    ) on the protected server, SQL backups have been working like a charm...

    Thank you.

    Monday, April 8, 2013 9:25 AM
  • I'm experiencing this issue as well, with my Configuration Manager 2012 R2 server.

    did you execute fsutil command from the cmd line of the protected server? If so, how did you calculate the values for expanding the USN Journal? Mines currently showing 32MB max size and what seems to be 8MB Allocation Delta.

    Tuesday, May 26, 2015 1:09 AM