SQL Server Data Recovery
SQL Server database recovery starts with the physical drive. When your server's storage has failed, software repair tools like DBCC CHECKDB cannot access the MDF file. We image the failed drive using PC-3000, extract the MDF/NDF files, and repair damaged pages at the hex level. SQL Server 2000 through 2022. No data, no fee.
MDF File Structure and What Goes Wrong
A SQL Server database consists of at least two files: the primary data file (.mdf) containing table data, indexes, and stored procedures, and the transaction log (.ldf) tracking every write operation for crash recovery. Larger databases split data across secondary files (.ndf) to distribute I/O.
The MDF file is organized into 8KB pages. Each page has a 96-byte header containing a page ID, checksum, and a Log Sequence Number (LSN) linking it to the transaction log. SQL Server verifies these checksums on every read. When a physical drive problem causes even a single byte to change in a page header, SQL Server flags the page as corrupt and may refuse to start the entire database.
Common corruption patterns from drive failures:
- Torn pages: The drive lost power mid-write. The 8KB page contains a mix of old and new data. SQL Server detects the checksum mismatch and reports Error 824.
- Zero-filled sectors: Bad sectors on the platter caused the drive to return null bytes. The page header is destroyed. SQL Server reports Error 823 (hard I/O error).
- Header corruption: The first page of the MDF (the file header page, page 0) is damaged. SQL Server reports Error 5171 and refuses to attach the database.
- GAM/SGAM/PFS corruption: The allocation bitmap pages that track which extents are in use are damaged. Tables appear empty or queries return partial results even though the data pages themselves are intact.
SQL Server Error Codes We Handle
| Error | Meaning | Typical Cause |
|---|---|---|
| Error 823 | Hard I/O error. The operating system returned an error during a read or write request. | Bad sectors, failing heads, loose SATA/SAS cable, RAID controller cache battery failure. |
| Error 824 | Logical consistency error. SQL Server read the page but the checksum does not match. | Torn page from power loss mid-write, RAID write-hole, SSD firmware bug causing silent data corruption. |
| Error 5171 | Cannot read the primary data file header. Database will not attach. | MDF file header page (page 0) is overwritten or unreadable. Often caused by severe drive degradation in the first sectors of the file. |
| Suspect Mode | Database marked suspect during recovery. SQL Server will not open it. | DBCC CHECKDB found corruption that the automatic recovery process could not resolve. The database is flagged to prevent further damage. |
| Error 9003 | Transaction log LSN is invalid or the log file does not match the data file. | LDF file was deleted, restored from a different backup, or the drive containing the log file failed independently. |
Why DBCC REPAIR_ALLOW_DATA_LOSS Is the Nuclear Option
Microsoft's documentation is clear: REPAIR_ALLOW_DATA_LOSS "may cause data loss" and should be used "only as a last resort." What the documentation does not emphasize is that this command permanently deletes any page it cannot validate, along with every row that references that page through foreign keys or indexes.
The command operates on the assumption that the MDF file is the best copy of the data that exists. But when corruption is caused by a physical drive problem (bad sectors, firmware corruption, failing read heads), the MDF file on disk may be incomplete or contain read errors. The same drive, imaged properly with PC-3000 using adaptive read parameters, often yields a more complete copy of the MDF with fewer damaged pages.
Running DBCC REPAIR_ALLOW_DATA_LOSS on a corrupted MDF that sits on a failing drive has two consequences: it deletes pages that could have been recovered from a proper drive image, and it modifies the MDF in place, making subsequent recovery more difficult if the repair does not produce an acceptable result.
Before running any repair command: Power down the server. Do not detach/reattach the database. Do not run ALTER DATABASE SET EMERGENCY followed by DBCC repair. Each operation writes to the MDF and reduces the data available for recovery. Contact us for a free evaluation of the drive's physical condition.
Our SQL Server Recovery Workflow
Drive assessment and forensic imaging
Evaluate the drive's physical condition using PC-3000 diagnostics. If the drive is mechanically sound, we image it with write-blocking. If heads are failed, we perform a head swap in the clean bench before imaging. The goal is a complete sector-level clone on a healthy drive.
MDF/NDF extraction from the image
Mount the cloned image and extract the database files. If the file system (NTFS, ReFS) is damaged, we parse the MFT or ReFS metadata directly to locate the MDF/NDF/LDF file extents on disk.
Page-level integrity scan
Scan every 8KB page in the MDF. Validate page headers, checksums, and LSN chains. Build a map of healthy pages, repairable pages, and unrecoverable pages. This assessment determines exactly how much data is recoverable before we commit to repair.
Hex-level page repair
Repair damaged page headers, recalculate checksums, and fix allocation bitmaps (GAM, SGAM, PFS pages). Rebuild the file header page if Error 5171 is present. Reconstruct the Page Free Space page chain so SQL Server can traverse the database correctly.
Transaction log rebuild and database attach
If the LDF is missing or corrupt, construct a minimal transaction log stub. Attach the database in a sandboxed SQL Server instance. Run DBCC CHECKDB (read-only, no repair) to validate the result. Export the data as a clean .bak backup file or detached MDF/LDF pair.
Suspect Mode: What It Means and How We Fix It
When SQL Server starts, it runs a recovery process on each database: redo committed transactions from the log, undo uncommitted ones. If this recovery process encounters pages it cannot read or validate, it marks the database as "suspect" and refuses to open it. The database appears in SSMS with a yellow warning icon.
The common advice online is to set the database to EMERGENCY mode, run DBCC CHECKDB with REPAIR_ALLOW_DATA_LOSS, then detach and reattach. This works when the corruption is limited to a few non-critical pages. When the corruption is extensive (dozens or hundreds of pages, often caused by a degrading drive), the DBCC repair deletes a large volume of data.
Our approach: image the drive, extract the MDF, repair pages at the hex level, and rebuild the transaction log. The repaired database can be attached directly in SQL Server without using EMERGENCY mode or running destructive DBCC commands. The number of recoverable rows depends on the extent of physical damage, but this method preserves pages that DBCC would have discarded.
Pricing
SQL Server recovery pricing is based on the physical condition of the drive. Database repair (page reconstruction, log rebuild, MDF header repair) is included at no additional charge. For RAID arrays, each member drive is priced separately.
| Service Tier | Price | Description |
|---|---|---|
| Simple CopyLow complexity | $100 | Your drive works, you just need the data moved off it Functional drive; data transfer to new media Rush available: +$100 |
| File System RecoveryLow complexity | From $250 | Your drive isn't recognized by your computer, but it's not making unusual sounds File system corruption. Accessible with professional recovery software but not by the OS Starting price; final depends on complexity |
| Firmware RepairMedium complexity – PC-3000 required | $600–$900 | Your drive is completely inaccessible. It may be detected but shows the wrong size or won't respond Firmware corruption: ROM, modules, or translator tables corrupted; requires PC-3000 terminal access Standard drives at lower end; high-density drives at higher end |
| Head SwapHigh complexity – clean bench surgery50% deposit | $1,200–$1,500 | Your drive is clicking, beeping, or won't spin. The internal read/write heads have failed Head stack assembly failure. Transplanting heads from a matching donor drive on a clean bench 50% deposit required. Donor parts are consumed in the repair |
| Surface / Platter DamageHigh complexity – clean bench surgery50% deposit | $2,000 | Your drive was dropped, has visible damage, or a head crash scraped the platters Platter scoring or contamination. Requires platter cleaning and head swap 50% deposit required. Donor parts are consumed in the repair. Most difficult recovery type. |
Hardware Repair vs. Software Locks
Our "no data, no fee" policy applies to hardware recovery. We do not bill for unsuccessful physical repairs. If we replace a hard drive read/write head assembly or repair a liquid-damaged logic board to a bootable state, the hardware repair is complete and standard rates apply. If data remains inaccessible due to user-configured software locks, a forgotten passcode, or a remote wipe command, the physical repair is still billable. We cannot bypass user encryption or activation locks.
All tiers: Free evaluation and firm quote before any paid work. No data, no fee on simple copy, file system, and firmware tiers. Head swap and surface damage require a 50% deposit because donor parts are consumed in the attempt.
Target drive: The destination drive we copy recovered data onto. You can supply your own or we provide one at cost. For ultra-high-capacity drives (20TB and above), the target drive costs approximately $400+ due to the large media required. All prices are plus applicable tax.
Data Recovery Standards & Verification
Our Austin lab operates on a transparency-first model. We use industry-standard recovery tools, including PC-3000 and DeepSpar, combined with strict environmental controls to make sure your hard drive is handled safely and properly. This approach allows us to serve clients nationwide with consistent technical standards.
Open-drive work is performed in a ULPA-filtered laminar-flow bench, validated to 0.02 µm particle count, verified using TSI P-Trak instrumentation.
Transparent History
Serving clients nationwide via mail-in service since 2008. Our lead engineer holds PC-3000 and HEX Akademia certifications for hard drive firmware repair and mechanical recovery.
Media Coverage
Our repair work has been covered by The Wall Street Journal and Business Insider, with CBC News reporting on our pricing transparency. Louis Rossmann has testified in Right to Repair hearings in multiple states and founded the Repair Preservation Group.
Aligned Incentives
Our "No Data, No Charge" policy means we assume the risk of the recovery attempt, not the client.
Technical Oversight
Louis Rossmann
Louis Rossmann's well trained staff review our lab protocols to ensure technical accuracy and honest service. Since 2008, his focus has been on clear technical communication and accurate diagnostics rather than sales-driven explanations.
We believe in proving standards rather than just stating them. We use TSI P-Trak instrumentation to verify that clean-air benchmarks are met before any drive is opened.
See our clean bench validation data and particle test videoSQL Server Recovery FAQ
Can you recover a SQL database stuck in suspect mode?
What is Error 5171 and can you fix it?
Should I run DBCC CHECKDB with REPAIR_ALLOW_DATA_LOSS?
Can you recover if the transaction log (LDF) is missing?
Do you support SQL Server Express and older versions?
How is SQL Server recovery priced?
Related Recovery Services
Recover Your SQL Database
Call Mon-Fri 10am-6pm CT or email for a free drive evaluation.