SQL Server Corruption: First Steps Before You Make It Worse
Database corruption in SQL Server usually shows up as an 824 error (a logical consistency error), a database marked SUSPECT, or DBCC CHECKDB reporting allocation or consistency errors. The instinct under pressure is to run the repair immediately — but SQL Server's built-in repair options work by deleting the corrupted pages, rows or index entries, not by reconstructing them. Once that's done, whatever was on those pages is gone for good.
Check for a clean recovery path first
Before any repair command runs, it's worth confirming: is there a recent full backup, plus transaction log backups since, that would let the database be restored without data loss? If the corruption is isolated (a single table, a single index) and a backup predates it, restoring — or restoring and replaying logs up to just before the corruption — is almost always safer than repair. If backups exist but their integrity hasn't been verified, verify them (RESTORE VERIFYONLY, or a test restore to a scratch instance) before relying on them.
If there is no clean backup, or the corruption predates every available backup, the database and its underlying MDF/LDF files themselves become the recovery source — and at that point, further writes to the affected database (including running REPAIR_ALLOW_DATA_LOSS) reduce what's recoverable rather than fixing anything.
What causes it
The most common root causes are storage-level: a failing disk, a RAID controller with a faulty battery-backed cache, an unexpected power loss during a write, or a SAN/VM snapshot inconsistency. Antivirus or backup software scanning live database files, and forced shutdowns of the SQL Server service, are frequent secondary causes. Identifying the underlying cause matters — repairing or restoring a database onto storage that's still failing just produces the same corruption again.
A safer sequence
Take the database offline or restrict access to prevent further writes. Copy the MDF/LDF files (or take a storage-level image) before running anything, so there's a fallback copy of the current state. Run DBCC CHECKDB without any repair option first, to see the scope of the damage. Only then decide between restore-from-backup, targeted recovery of the affected objects, or full repair — in that order of preference.
Dealing with something like this now?
Contact AS for an initial assessment of your recovery situation.