• State Not Answered
  • Replies 4 replies
  • Subscribers 29 subscribers
  • Views 1830 views
  • Users 0 members are here
Options
Related

Failing rollup A repository record checksum mismatch was detected.

johnny
10 months ago

Hello This happened about 1 week ago and currently It is only having issues rolling up doing the transfers are successful. The full error when I click on details is:

A repository record checksum mismatch was detected.

Error writing 0x2bbe bytes at offset 0x0 from file 0x10000000734aaf on volume 0x2 - Error(s) 'DvmChecksum'

I believe that the repository is located locally on the device that has the quest software installed.

I checked the logs and this would happen right after it says start of rollup operation:

There are no available chains to rollup for 'XXXXX'

Let me know if more information is needed or if there are any quick fixes I can try.

  • 0 10 months ago

    "A repository record checksum mismatch was detected" is due to either

    1. hardware failure (Normally disk, memory)
    2. Logical volume problems (File system issues)

    Take a look at the event viewer on the Core server to see if there are any hints of possible hardware or logical volume issues. You can check Event Viewer > Windows Logs > System and it should give you solid information about what is going on. 

    Normally once those issues are resolved the errors are gone as well, however there is a chance the problem persist even when those has been taken care of, if that is the case you will need to create a case with support for them to run a repository tool to help you out with the issue or recreate the repository.

  • 0 10 months ago

    Had a similar checksum mismatch issue last week. Mine was sorted by updating the software. Maybe try that? Also, double-check if your local repository is in good shape. Logs can be tricky, but keep an eye on any clues right after the rollup operation starts.

  • 0 10 months ago in reply to Victor.Portillo

    I just went and looking into a few more things and currently the server is showing that the recovery points are all of the sudden all orphaned and I am testing the mounts often and this is the first time I am trying since this issue and its not working now because all the  recovery points changed to "incremental, orphan". I had an issue where the system reserve volume went into an orphan state but not all the volumes so now I'm wondering if there might be something that I should be looking into differently now that this is the case? 

  • 0 10 months ago in reply to johnny

    Orphans happen most of the time due to hardware issues or unexpected shutdowns, either by a Windows update causing the OS to restart without stopping the core service properly or just forgetting to stop the core service before a system restart/shutdown. You can take a look to the event viewer to check if there was any unexpected shutdown recently. 

    Once you confirm the hardware is in good shape the fastest option to get up and running is to delete the orphans and take a new base image.