December 1, 2025 at 12:00 am
Comments posted to this topic are about the item Troubleshooting Common SQL Server Errors: 823, and 824
December 1, 2025 at 8:15 am
Insightful , thank you for the information. One comment I do have
"If the database is accessible, take the backup. The backup might be used to restore the data which is inaccessible." >
I would first go for the transaction log backup as you may already have a full backup with periodic log backups. Backing up the current DB file may be of no use if the I/O system has already corrupted it.
----------------------------------------------------
December 13, 2025 at 3:50 am
Errors 823 and 824 usually point to underlying I/O or storage subsystem problems rather than a SQL Server engine issue. While taking full and transaction log backups is important if the database is still accessible, it’s worth noting that backing up after corruption has already occurred may simply preserve the corrupted pages. The recommended approach is to run DBCC CHECKDB to understand the extent of the corruption, then restore from the last known good full backup along with any subsequent log backups. If clean backups aren’t available, options become limited and may include repairing with potential data loss or exporting data from unaffected objects. At the same time, the storage subsystem should be investigated immediately by reviewing OS and hardware logs, as recurring 823/824 errors often indicate disk, controller, driver, or firmware issues that must be resolved to prevent further corruption.
December 16, 2025 at 5:04 pm
Backing up will almost certainly preserve corruption, but ensuring you have a backup is critical. l'd certainly make an extra one before I start doing anything. Never know when someone else might run repair on the system
December 16, 2025 at 6:07 pm
This was removed by the editor as SPAM
Viewing 5 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply