The MDF Was Recovered, but SQL Server Says It Is Corrupt and the Application Is Still Down

The RAID may be online again and the MDF may have the expected name and size, yet SQL Server reports page errors, consistency failures, attach errors, or an unusable database. At this point the question is not simply whether the file exists. It is whether the storage reconstruction and the database pages can be trusted.

What this condition means

A corrupt MDF can be the result of database damage that existed before the outage, incomplete writes during the failure, unreadable sectors, filesystem damage, or a plausible but incorrect RAID reconstruction. SQL Server reports the damaged structures it encounters; the error does not by itself identify which layer produced them.

A mounted volume and a correctly sized MDF do not prove that every database block came from the right member, stripe, or point in time. If the array was rebuilt, recreated, or reconstructed, the storage result and the database result must be validated separately.

What to record

• Exact SQL Server errors, DBCC output, and database state
• SQL Server version, database size, recovery model, and application name
• Every MDF, NDF, LDF, backup, snapshot, and recovered file version
• RAID level, controller, member identities, failures, replacements, and rebuild history
• File-recovery, attach, repair, restore, or log-rebuild attempts already made
• The tables, records, dates, and business functions needed first

What not to do

• Run repair with data loss on the only MDF
• Create or rebuild a transaction log beside the only database copy
• Keep attaching, detaching, or modifying the first recovered files
• Discard an earlier or alternate recovered file set
• Assume the file size or a mounted filesystem proves the database is complete
• Write repaired output back to the affected RAID

How ADR evaluates it

ADR first identifies the provenance of each recovered file set and validates the RAID reconstruction that produced it. Work then proceeds from protected database copies so that storage alternatives remain available.

Database structures are compared with the records the business actually needs. A candidate is not accepted merely because SQL Server opens it; required tables, dates, relationships, and application data must also be coherent.

What happens next

A corrupt MDF does not establish that all business data is lost. The defensible result depends on which pages remain readable and internally consistent, the condition of related files and logs, prior repair attempts, and whether a better storage reconstruction or file version exists.