Error -1018 JET_errReadVerifyFailure: page checksum damage in a mailbox database

Fix it now

Microsoft publishes -1018 as JET_errReadVerifyFailure, a checksum error on a database page. The engine verifies every page as it reads it, so this is the database telling you the bytes on disk are not the bytes it wrote. Get a clean copy of the data; do not repair the file in place.

Get-MailboxDatabaseCopyStatus * | Format-Table Name,Status,CopyQueueLength,ReplayQueueLength,ContentIndexState
Suspend-MailboxDatabaseCopy -Identity DB01\SERVER2
Update-MailboxDatabaseCopy -Identity DB01\SERVER2 -DeleteExistingFiles -SourceServer SERVER1
Resume-MailboxDatabaseCopy -Identity DB01\SERVER2

1. Find the engine entry in the Application log and note the database, file, offset and page it names.
2. Read the System log for the same period. Disk, storage port and controller entries around the failure are the strongest signal about the real cause, and several databases on one volume points at the storage they share.
3. If there is no healthy copy, restore from the last known good backup and replay the logs. That is the only route that returns all of the data.
4. Before bringing anything back into service, fix the antivirus exclusions on every Exchange server, passive members included.

Microsoft requires a database copy to be suspended before Update-MailboxDatabaseCopy will run, and -DeleteExistingFiles removes only the log files it checks for: it fails if other files are present, so database files at the target must be removed by hand.

If the reseeded copy is healthy and the queues have drained, you are done. If there is no copy and no backup, the next sections matter a great deal.

Why it happens

The engine writes fixed-size pages, each carrying a checksum, and recalculates it on every read. A mismatch means the bytes on disk are not the bytes it wrote, and it has no way to know which byte changed or what it should have been. Refusing the read is the only safe response. Microsoft’s published description is exactly that: JET_errReadVerifyFailure, there is a checksum error on a database page.

Because verification happens on read, the damage was done earlier, sometimes much earlier. A page nobody has touched for months can sit corrupt until a search or a backup finally reads it. The suspect is always the write path: a controller cache that lost power without battery protection, a firmware or driver defect, a failing disk, or a virtualisation layer that acknowledged a write it had not committed.

The other classic cause is a file-level scanner with its hands on the database and log files. Microsoft is unusually direct about this: the biggest potential problem is that a program such as antivirus might lock or quarantine an open log or database file that Exchange needs to modify, and this can cause severe Exchange Server issues including potential data loss. If the published exclusions were never applied here, you have found something to fix regardless of what else you find.

Full reference

What the code family says

The engine event IDs that report a page verification failure are not published by Microsoft, so read the file, offset and page numbers from your own entries and use them to establish scope: one page in one database is a different conversation from a page failing on every database on a volume.

A hard repair discards whatever it cannot read and does not tell you what it deleted. Run it against a copy, never the original. Afterwards the file must be defragmented and every mailbox moved into a freshly created database. A repaired database is a vehicle for extracting data, not one you continue to run.

A note on eseutil

Microsoft no longer publishes a current reference page for eseutil, so this article does not present its switches as documented syntax. The tool ships with Exchange and prints its own mode list when run without arguments; confirm the switch you want there before running anything against a database file, and take a copy first. Everything in the fix layer above uses cmdlets that are documented.

Reseeding correctly

1. Suspend the copy first. Microsoft states you must suspend a database copy before you can update it.
2. Choose the source deliberately with -SourceServer, which names a Mailbox server holding a passive copy to seed from.
3. Use -DeleteExistingFiles knowing what it does: it removes only the files it checks for and fails if other files are present, taking no action on anything else at the target.
4. For a long seed, -BeginSeed starts it asynchronously and exits, and -ManualResume leaves you to resume replication yourself.
5. If only the search catalogue needs rebuilding, -CatalogOnly seeds that alone; catalogue seeding always uses the MAPI network regardless of -Network.

When it happens again

• One page failing verification is evidence that the write path is not trustworthy. The next occurrence may land somewhere more important than a message body.
• Compare counts over time on a dismounted copy rather than assuming. If the number grows, the cause has not been fixed.
• Keep watching the System log for storage errors for at least a full backup cycle after the change.
• Confirm the exclusions were applied on the passive members too. They are routinely forgotten, and a passive copy is a database file like any other.

Every code this article covers

Confirm the fix worked

1. The database mounts, stays mounted, and clients can open the mailboxes it holds.
2. Every copy reports healthy with copy and replay queues near zero and a healthy content index state.
3. No new page verification entries or storage errors appear in the Application and System logs over a full day.
4. Microsoft’s published exclusions are in place on every Exchange server, including passive members.

Questions people ask about this