ERROR 2013-09-16T05:25:15 [171] – Replay.Core.Implementation.Exchange.ChecksumChecks.Jobs.ChecksumCheckQueueEntry ()
Checksum check task ’71a02f55-ea41-4aa1-9fc5-6e69e063e699′ failed
System.AggregateException: One or more errors occurred. —>
System.AggregateException: One or more errors occurred. —>
System.AggregateException: One or more errors occurred. —> Replay.Core.Contracts.Exchange.ChecksumChecks.ChecksumCheckFailedException: Checksum check failed for database ‘E:\MailData\CSW\MalboxStoreCSW.edb’ with ’8′ checksum mismatches
A checksum is a simple redundancy check that is used to find errors within data. Errors can occur within data blocks when it is written to disk, transmitted across a network, or altered by some other means. At times these errors can be very small and only affecting a piece as small as one bit, but there are events that checksum errors do affect the exact integrity of the data.
A checksum is created by calculating the binary values in a block of data using an algorithm that is then stored within the data. When the data is received at the other end of the network a new checksum is calculated and compared with the existing checksum and non-matches indicate errors.
Rapid Recovery uses a proprietary intelligent check algorithm that reads the Smart Agent change log.
The checksum algorithm finds the for the most recent previous recovery point for which the EDB checksum check was successful. If there is none, or if there is a base image newer than the last successful recovery point, the checksum check is a full check, in which every single EDB page is read and verified. If a successful checksum check exists, then only the changed pages are verified. This process takes several steps.
Solution 1:
Force a checksum check to ensure that the error is not a false event.
If the checksum check fails, snap a new base image to reset the incremental chain.
Soluton 2:
If you have Exchange 2013 running on your agent, please perform the following steps:
Set this value to 1
Note: They change the way of performing the check using a different algorithm. In some cases that fixes the issue.
Solution 3:
There is a possibility that Rapid Recovery is making good backups of a corrupted database. If the new base image does not resolve the issue, then there is a real possibility that the database itself is bad. Please run ESEUTIL /K, (checksum check) against the Exchange database. If errors occur, consider running ESEUTIL /P (repair) against the database. For more information about using ESEUTIL, see https://technet.microsoft.com/en-us/library/aa996953(v=exchg.65).aspx.
NOTE: These checks will require dismounting the Exchange databases and running the command could remove critical data, per the below KB. So, please, if need be contact Microsoft or your Exchange provided.
https://support.microsoft.com/en-us/kb/259851
© 2024 Quest Software Inc. ALL RIGHTS RESERVED. Terms of Use Privacy Cookie Preference Center