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.
Torn Page Detection: How SQL Server Identifies Partial Writes
SQL Server writes data in 8KB pages. The underlying storage layer does not. NTFS formats with 4KB allocation units by default, and NVMe SSDs write in 4KB or 16KB physical sectors depending on the controller. When a power failure interrupts a write, the operating system may commit one 4KB sector of an 8KB SQL page but fail to write the second. The result is a page where half the data is current and half is stale. SQL Server calls this a torn page.
SQL Server provides two detection mechanisms, configured per-database through the PAGE_VERIFY option:
- TORN_PAGE_DETECTION (legacy): Before writing each 8KB page, SQL Server saves a 2-bit pattern from the first two bytes of every 512-byte sector within the page. On read, it compares the stored bits to the current values. If a sector was partially overwritten, the bit pattern will not match. This method detects torn writes but does not catch silent bit-rot or single-bit errors within a sector.
- PAGE_VERIFY = CHECKSUM (modern): SQL Server computes a checksum over the entire 8KB page before writing it to disk. On every subsequent read, it recomputes and compares. This catches torn writes, bit-rot, and firmware-induced corruption. CHECKSUM is the default for SQL Server 2005 and later, but it is not retroactive; pages written before the setting was enabled remain protected only by the older mechanism until an index rebuild forces a page rewrite.
When either check fails, SQL Server reports Error 824 for the affected page. If enough pages fail during the startup recovery process, the database enters suspect mode and SQL Server refuses to open it. The standard DBA response is to run DBCC CHECKDB with REPAIR_ALLOW_DATA_LOSS, but that command deallocates every corrupted page and permanently deletes the rows stored on it.
Repairable vs. Unrecoverable Torn Pages
Not every torn page means lost data. The outcome depends on which part of the 8KB page was interrupted. Each SQL Server data page has a 96-byte header containing the page ID, object ID, slot array offset, and LSN. The remaining bytes store the actual row data.
- Header intact, payload torn: The page header survived, but some row data in the lower half of the page contains stale bytes. We identify which row offsets were affected by comparing the slot array against the physical byte boundaries, reconstruct valid rows from the intact portion, and recalculate the page checksum. Rows spanning the torn boundary may be partially recoverable depending on column data types and NULL bitmap alignment.
- Header torn: The page header itself was partially overwritten. SQL Server cannot identify the page at all. We reconstruct the header by inferring the page ID from its position in the MDF file (page ID = byte offset / 8192), reading the object ID from the sys.allocation_units metadata, and rebuilding the LSN from the transaction log if the LDF is intact.
- GAM/SGAM torn pages: When a torn write hits the Global Allocation Map or Shared Global Allocation Map pages, SQL Server loses track of which extents are allocated. Tables appear empty or queries skip rows stored on "orphaned" extents that the allocation bitmap no longer references. We rebuild the GAM/SGAM by scanning every data page in the MDF and reconstructing the allocation chain from scratch.
The common thread: imaging the failed drive with PC-3000 before attempting any repair gives us a complete sector-level snapshot. Multiple imaging passes with adaptive read parameters often recover sectors that a single read missed, reducing the number of torn pages in the final MDF copy.
Transaction Log Replay for Torn Page Recovery
When the LDF transaction log is intact but the MDF has torn pages, the log contains the after-image of the interrupted write. SQL Server's normal crash recovery would replay these log entries automatically, but it refuses to do so when the database is in suspect mode.
Our procedure: extract the relevant log records for the torn pages by parsing the LDF at the byte level. Each log record contains the page ID, the operation type (INSERT, UPDATE, DELETE), and the before/after images of the affected row. If the log record contains a complete after-image of the data that was being written when power failed, we apply it directly to the torn page in the MDF, recalculate the checksum, and update the page LSN. This completes the interrupted write without involving DBCC repair commands.
This approach works when the LDF and MDF reside on separate physical drives, which is standard practice in production SQL Server deployments. If both files share a single drive, the same physical failure that created the torn MDF pages may have also damaged the LDF, limiting what the log replay can reconstruct. In that scenario, we fall back to hex-level page repair using the methods described above, and any in-flight transactions at the moment of failure are lost. For RAID arrays hosting SQL Server, a RAID 5 write-hole event during power loss can corrupt both the MDF parity stripe and the LDF simultaneously; rebuilding the array in that state destroys the data rather than recovering it.
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.
Simple Copy
Low complexityYour drive works, you just need the data moved off it
$100
3-5 business days
Functional drive; data transfer to new media
Rush available: +$100
File System Recovery
Low complexityYour drive isn't recognized by your computer, but it's not making unusual sounds
From $250
2-4 weeks
File system corruption. Accessible with professional recovery software but not by the OS
Starting price; final depends on complexity
Firmware Repair
Medium complexityYour drive is completely inaccessible. It may be detected but shows the wrong size or won't respond
$600–$900
3-6 weeks
Firmware corruption: ROM, modules, or translator tables corrupted; requires PC-3000 terminal access
CMR drive: $600. SMR drive: $900.
Head Swap
High complexityMost CommonYour drive is clicking, beeping, or won't spin. The internal read/write heads have failed
$1,200–$1,500
4-8 weeks
Head stack assembly failure. Transplanting heads from a matching donor drive on a clean bench
50% deposit required. CMR: $1,200-$1,500 + donor. SMR: $1,500 + donor.
50% deposit required
Surface / Platter Damage
High complexityYour drive was dropped, has visible damage, or a head crash scraped the platters
$2,000
4-8 weeks
Platter scoring or contamination. Requires platter cleaning and head swap
50% deposit required. Donor parts are consumed in the repair. Most difficult recovery type.
50% deposit required
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.
No data, no fee. Free evaluation and firm quote before any paid work. Full guarantee details. Head swap and surface damage require a 50% deposit because donor parts are consumed in the attempt.
Rush fee: +$100 rush fee to move to the front of the queue.
Donor drives: Donor drives are matching drives used for parts. Typical donor cost: $50–$150 for common drives, $200–$400 for rare or high-capacity models. We source the cheapest compatible donor available.
Target drive: The destination drive we copy recovered data onto. You can supply your own or we provide one at cost plus a small markup. For larger capacities (8TB, 10TB, 16TB and above), target drives cost $400+ extra. 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?
What is a torn page in SQL Server?
Does changing PAGE_VERIFY to CHECKSUM protect existing data?
Related Recovery Services
Recover Your SQL Database
Call Mon-Fri 10am-6pm CT or email for a free drive evaluation.