SQL Server page integrity

SQL Server error 823 or 824 is a storage-integrity incident, not just a database warning.

Error 823 reports an operating-system I/O failure, while error 824 means the read completed but SQL Server found an invalid page, checksum, torn-page, or logical consistency result. Both require the database and the storage path to be preserved together.

Understand the symptom

A successful read can still return the wrong database page.

WHY

What is happening

SQL Server checks page identity and protection fields after the operating system reports a completed read. Recovery must distinguish media I/O, stale or misdirected writes, damaged page content, and broader allocation damage, then compare backups, replicas, suspect_pages history, and related pages before selecting a restore or extraction path.

What you may see

Symptoms that change the recovery path.

01

Error 823 in the SQL log

The operating system returned a short read, CRC, device, or other I/O failure.

02

Error 824 with page ID

SQL Server read the block but rejected its checksum, torn-page, page ID, or logical structure.

03

DBCC CHECKDB reports corruption

Allocation or consistency checks identify damaged pages, indexes, or objects.

04

Queries fail on one table or range

A specific page may be reached only by particular keys, scans, or maintenance jobs.

Protect the source

Actions that can make the situation worse.

01

REPAIR_ALLOW_DATA_LOSS can remove records

The name is literal: consistency may be restored by deallocating damaged structures.

02

Repeated full scans stress failing storage

CHECKDB, backup, and index rebuilds can intensify I/O on an unstable array.

03

Restoring over the only instance destroys evidence

An in-place restore can replace pages needed to compare generations and salvage records.

Do this now

Safe steps before evaluation.

01

Quiesce nonessential writes

Stop maintenance, index rebuilds, backup churn, and application jobs while preserving required service evidence.

02

Capture exact errors

Record database, file, page ID, offset, time, query, error log, Windows events, and storage alerts.

03

Preserve every database component

Copy MDF, NDF, LDF, backups, encryption material, configuration, and replica state as a consistent set.

04

Snapshot or image the storage

Protect the affected LUN or member disks before repair, detach, firmware work, or controller changes.

NEPFOSYS process

How a data-first evaluation proceeds.

01

I/O-path review

NEPFOSYS correlates SQL errors with database files, storage events, and the physical or virtual storage layer.

02

Page and backup comparison

Affected pages and objects are mapped against intact backups, replicas, logs, and neighboring structures on copies.

03

Validated recovery output

Restored or extracted databases are checked for requested tables, records, and application consistency.

A clear next step

Preserve the original device before another repair or recovery attempt.

Start a case with the exact symptoms, incident timeline, prior attempts, encryption details, and the files that matter most. NEPFOSYS will route the case to the appropriate DFW intake or nationwide mail-in path.

Start with a case review

Questions, answered

What customers ask before starting.

What is the difference between error 823 and 824?

Error 823 is an operating-system I/O failure. Error 824 means the read completed but SQL Server detected an invalid page or protection result.

Can DBCC repair error 824?

Sometimes, but repair can deallocate damaged content. Preserve the source and evaluate clean restore, replica, page restore, and extraction options first.

Does error 824 prove the drive is bad?

No. The fault may involve media, controller, cabling, cache, virtualization, firmware, memory, or a prior misdirected write. The full path must be reviewed.

DFW local · Nationwide mail-in

Protect the device. Start with the facts.

Start my recovery case