How to fix SQL Server errors 823 and 824 (I/O errors)
These mean SQL Server hit an input or output error reading or writing a page. 823 is a hard error the operating system reported, 824 is a page that read back wrong. Both point at storage trouble or corruption and must be fixed quickly. Jump to your situation below or work through the methods in order.
By Neeraj Singh ~11 min Updated Jun 2026 92% found this helpful
Error message
Error: 824, Severity: 24, State: 2. SQL Server detected a logical consistency-based I/O error: incorrect checksum (expected: 0x246e3cb2; actual: 0x24663cb2). It occurred during a read of page (1:1314) in database ID 5 in file 'YourDB.mdf'.
Summary
Errors 823 and 824 are I/O errors that threaten database integrity. 823 means the operating system returned a hard error to SQL Server during a read or write, so the storage, controller or driver is at fault. 824 means the read succeeded but the page failed a logical check such as a checksum mismatch, a torn page or a wrong page id, which is usually corruption caused by the I/O subsystem. Start by reading the exact message and the msdb..suspect_pages table, run DBCC CHECKDB on the affected database, then restore from a known-good backup, which is the cleanest fix. Page-level restore can fix an isolated page. Always investigate the disk hardware, turn on PAGE_VERIFY CHECKSUM, and keep REPAIR_ALLOW_DATA_LOSS as a last resort because it can drop data.
What this error means
Error 823 is raised when SQL Server calls a Windows file API to read or write a page and the operating system returns an error, for example “The request could not be performed because of an I/O device error”. SQL Server retries a read four times, and if a retry succeeds you get a warning (error 825) instead. A persistent 823 almost always means a real storage, controller or driver problem.
Error 824 is subtler. The operating system says the read worked, but SQL Server checks the page and finds it inconsistent, such as a checksum that does not match or a page id that is wrong. That points at the I/O subsystem silently damaging data, a torn write from a power loss, or corruption already on disk. Both errors are Severity 24 and demand immediate action because they put your data at risk.
Common causes
A failing disk or bad sectors on the volume holding the database file.
A storage controller or its firmware is faulty or misconfigured.
An outdated or buggy device driver in the I/O path.
A torn page from an incomplete or interrupted write, often after a power loss.
Controller or disk write-caching corrupted the page before it reached disk.
A filter driver such as antivirus or backup software interfered on the I/O path.
A network or SAN dropout for database files stored on remote storage.
Expert insight
“823 and 824 are the database equivalent of a smoke alarm, they are telling you the storage underneath is sick. The mistake I see is people reaching for REPAIR_ALLOW_DATA_LOSS first, which can throw away the very data you are trying to save. My order is fixed: read the page id from the message, check suspect_pages, run CHECKDB, and restore from a clean backup if I have one. If only a page or two are hit, a page-level restore is surgical and loses nothing. Repair with data loss is the last thing I try, and only after I have copied out everything I can and found the failing disk.”
Manager, Tech Support & Operations · 19+ years fixing Windows and system errors
✓ How to fix it
Method 1
Read the exact error and check suspect_pages
1Note whether it is 823 or 824, the database, the file and the page id from the message.
2List every page SQL Server has flagged as damaged:
SELECT * FROM msdb..suspect_pages;
3A single page id suggests isolated corruption, while many pages or several databases on one volume point at a failing disk.
Method 2
For 823, fix the operating system or hardware error first
1The 823 message includes the OS error, for example 1117 (I/O device error) or 21 (device not ready). Address that error before anything else.
2Check the Windows System and Application event logs for disk and controller messages such as “The driver detected a controller error” around the same time.
3If a read retry succeeded you will also see error 825 in the log, which is an early warning that the disk is starting to fail.
Method 3
Run DBCC CHECKDB on the affected database
1Check the database, and others on the same volume, for consistency:
DBCC CHECKDB ('YourDB') WITH NO_INFOMSGS, ALL_ERRORMSGS;
2Read the output for the minimum repair level it recommends and the objects affected.
3Note that CHECKDB checks data and index pages, not the transaction log, so a clean result does not rule out a disk problem.
Method 4
Restore from a known-good backup (preferred)
1If you have a clean backup, restoring is the safest fix and loses nothing up to the last backup. Restore the full backup then the log chain.
2After the restore, run DBCC CHECKDB again to confirm the database is consistent.
3If the restore itself reports 823 or 824, that backup is also damaged, so use an earlier one.
Method 5
Restore just the corrupt page if it is isolated
1When only one or a few pages are damaged and the database is in FULL recovery, a page-level restore is surgical:
RESTORE DATABASE [YourDB] PAGE = '1:1314'
FROM DISK = 'D:\Backup\YourDB_full.bak' WITH NORECOVERY;
2Apply the later log backups, then take a final tail-log backup and restore it WITH RECOVERY to keep the log chain intact.
3Run CHECKDB once more to confirm the page is now clean.
Method 6
Check and fix the disk and I/O subsystem
1Run chkdsk on the volume, review the drive SMART health, and use your storage vendor diagnostics.
2Test the I/O path outside SQL Server with the SQLIOSim utility, and update controller firmware and disk drivers.
3Exclude the database and log files from antivirus and backup filter drivers so they cannot corrupt the I/O path.
Method 7
Last resort: repair with data loss
1Only if there is no usable backup, put the database in single user and run the repair, accepting possible data loss:
ALTER DATABASE [YourDB] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
DBCC CHECKDB ('YourDB', REPAIR_ALLOW_DATA_LOSS) WITH ALL_ERRORMSGS;
ALTER DATABASE [YourDB] SET MULTI_USER;
2REPAIR_ALLOW_DATA_LOSS can deallocate damaged pages and rows, so copy out anything critical first.
3It is not guaranteed to fix every error, and it does not address the failing hardware underneath.
Method 8
Turn on CHECKSUM and monitor
1Make sure page checksums are on so future damage is caught early:
ALTER DATABASE [YourDB] SET PAGE_VERIFY CHECKSUM;
2Schedule regular DBCC CHECKDB jobs and set up SQL Server Agent alerts for errors 823, 824 and 825.
3Alert on new rows in msdb..suspect_pages so corruption is flagged the moment it appears.
REPAIR_ALLOW_DATA_LOSS is the minimum repair level for these errors, but it works by deallocating the damaged pages, which can permanently remove rows. It is never a substitute for a restore. Treat 823 and 824 as a hardware warning: even after a clean repair or restore, find and replace the failing disk or controller, or the corruption will simply come back.
Frequently asked questions
What is the difference between error 823 and 824?
823 means the operating system returned a hard I/O error to SQL Server during a read or write. 824 means the read succeeded but the page failed a logical check such as a checksum mismatch, which usually signals corruption from the I/O subsystem.
Can DBCC CHECKDB fix errors 823 and 824?
CHECKDB finds and can sometimes repair page corruption, but its repair option can lose data and it does not check the transaction log. The clean fix is to restore from a known-good backup.
Should I run REPAIR_ALLOW_DATA_LOSS?
Only as a last resort with no usable backup. It deallocates damaged pages, which can remove rows, so copy out critical data first and still replace the failing hardware afterwards.
What is SQL Server error 825?
825 is a read-retry warning. SQL Server retries a failed read up to four times, and if a retry succeeds it logs 825 instead of 823. It is an early sign the disk is starting to fail.
Will I lose data fixing these errors?
Not if you restore from a clean backup or restore only the affected pages. You only risk data loss if you repair with REPAIR_ALLOW_DATA_LOSS because you have no backup.
How do I prevent 823 and 824 errors?
Turn on PAGE_VERIFY CHECKSUM, run regular CHECKDB and backups, alert on 823, 824, 825 and suspect_pages, and keep disk firmware and drivers up to date on healthy storage.
Still not working?
If CHECKDB still reports corruption after a restore or repair, the underlying disk is almost certainly still failing and re-damaging pages. Move the database to healthy storage, restore the most recent backup that passes CHECKDB, and engage your storage vendor to replace the faulty hardware. You can also submit your error to us for a tailored fix.
