SQL Server Database Suspect or MDF Won't Attach? Don't Force Repair.
UK SQL Server data recovery specialists since 2002. Corrupt MDF and LDF files, suspect databases, DBCC repair failures, deleted records. SQL Server 2008 through 2022. Emergency turnaround. No-fix-no-fee.
DBCC CHECKDB REPAIR_ALLOW_DATA_LOSS as a first response, do not detach a suspect database, and do not delete the transaction log file. SQL Server's built-in repair commands are powerful but invasive — REPAIR_ALLOW_DATA_LOSS is, as the name says, allowed to discard data to restore consistency. On a database where the structural damage is small, repair often works; on more damaged databases it can discard recoverable rows. Detaching a suspect database changes its state in ways that make later forensic recovery harder. Stop, take a forensic copy of the MDF and LDF files, and call 0800 151 2207.What this means and what to do next
Microsoft SQL Server stores data in MDF files (primary database) and optionally NDF files (secondary), with a transaction log in an LDF file. Together they form the database. Most SQL Server data loss originates outside SQL Server — a failed disk, a RAID rebuild gone wrong, a virtualisation incident, ransomware — and SQL Server reports the database as suspect, recovery pending, or emergency as a downstream effect. Recovery is a two-layer problem: get back the bytes of the MDF/LDF first, then make SQL Server willing to attach them.
When SQL Server marks a database as suspect, it has detected a consistency problem during startup recovery — usually a torn page write, a checksum mismatch, or a transaction log entry that cannot be replayed cleanly. SQL Server's response is to refuse to bring the database online until the problem is resolved. The administrator's options are documented: emergency mode + DBCC CHECKDB, restore from backup, or replace from a replica. Each of those has a known failure mode and a known correct sequence; getting it wrong is the most common reason a recoverable database becomes a recovery lab case.
Beyond corruption recovery, SQL Server has a second class of recovery work: deleted-row recovery and dropped-object recovery. SQL Server pages are not zeroed when records are deleted — they are marked for reuse. A deleted table, a TRUNCATE'd table, or rows deleted by a DELETE statement remain on the data pages until they are overwritten by new inserts. The window for recovery is short (until those pages are reallocated), but in practice it is often hours to days, especially on production databases with predictable load patterns.
The four most common SQL Server recovery scenarios
1. Database marked suspect after an unclean shutdown. Symptom: SQL Server reports the database in state suspect or recovery pending, the database is not online, applications fail to connect. Cause: host crashed (power loss, BSOD, hypervisor failure) while transactions were in flight, transaction log entries cannot be cleanly replayed, SQL Server has refused to bring the database online. Recovery: forensic copy of MDF and LDF files first, then either coax SQL Server through a controlled emergency-mode recovery (preserving data) or, if the log is too damaged, extract data directly from the MDF pages using specialist tooling. The choice depends on what's recoverable from the log.
2. MDF or LDF file corrupt at the file system level. Symptom: SQL Server cannot attach the database, reports the file as corrupt or unreadable, or attaches it and immediately marks it suspect on first read. Cause: filesystem-level corruption — usually from a disk failure, RAID rebuild damage, or a controller fault — has damaged the bytes of the MDF or LDF file. Recovery: file-level recovery of the MDF/LDF (NTFS or ReFS recovery, depending on the host filesystem), then attempt attach. If the MDF is still damaged after file recovery, page-level extraction of the data using specialist SQL Server forensic tooling.
3. DBCC CHECKDB reports unrepairable damage or REPAIR_ALLOW_DATA_LOSS has been run. Symptom: administrator ran DBCC CHECKDB which reported errors, then ran DBCC CHECKDB REPAIR_ALLOW_DATA_LOSS to fix them — and significant data is now missing. Cause: REPAIR_ALLOW_DATA_LOSS does exactly what its name suggests: it discards data to restore the database's consistency. Recovery: if a forensic copy of the pre-repair MDF and LDF exists, we recover from that — many of the rows DBCC discarded are still recoverable from the original pages. If the post-repair files are all that exists, recovery is limited to what's still in the discarded-pages free space, which is often partial.
4. Accidental DROP TABLE, TRUNCATE, or DELETE — undelete from data pages. Symptom: production data is gone, no recent backup, the missing data was lost to a TRUNCATE TABLE, DROP TABLE, or DELETE statement (often an unguarded production query). Cause: SQL Server marked the affected pages as free but the data is still on disk in those pages until they are reused. Recovery: forensic snapshot of the database (in-place if SQL Server allows, or as a copy of the MDF/LDF if not), then page-level extraction of the deleted records using SQL Server forensic tools. Time-sensitive — the longer the database keeps running and writing, the smaller the recovery window.
How Data Clinic recovers a SQL Server database
Step one is a triage call. We ask which SQL Server version (2008, 2008 R2, 2012, 2014, 2016, 2017, 2019, 2022), what the database state is, what error messages SQL Server is reporting, what recovery attempts have already been made, whether the underlying drives or storage are healthy, and what the recovery objective is — full database restore, specific tables only, or specific rows from a known time. The objective matters: a 'recover everything' job and a 'recover the customers and orders tables' job are sized differently.
Step two is a forensic copy. Before any repair attempt, we (or your team, under our direction) take a binary copy of the MDF, LDF, and any NDF files. This is non-negotiable — if the first recovery approach makes things worse, the original state is preserved for a second approach. The forensic copy is stored offline; recovery work happens against working copies.
Step three is the layered recovery. Page-level extraction of the data using specialist SQL Server forensic tools is the workhorse — it works against MDF files that SQL Server itself refuses to attach. We can extract tables, views, indexes, stored procedure definitions, and (within limits) data from system catalogs. Where the MDF is too damaged for direct extraction, we drop to lower-level recovery against the underlying NTFS/ReFS or RAID. Recovered data is delivered as: an attachable MDF (where the database is repairable), SQL scripts (CREATE TABLE + INSERT) that can be replayed into a fresh database, or CSV/Excel exports for ad-hoc consumption. We provide a written report covering the failure mode, the data recovered, the data not recovered, and the recommended go-forward database integrity actions. More on our hard drive data recovery service →.
Get a free initial diagnosis in 60 seconds
In the tool below, choose Files lost or inaccessible and tell us SQL Server — we will route the case to the database recovery team. If the underlying drive has failed as well, we handle both layers in a single job.
What our customers say
"Three years of family photos on a drive that suddenly failed. Data Clinic collected next day, kept me updated through the cleanroom work, and got everything back. Worth every penny."
"Honest, fixed-price, no-fix-no-fee. Quoted by another lab at three times the price. Recovered 100% of my files."
"Reasonable cost, clear communication, and they were straight with me about what was recoverable and what wasn't. Recommended."
Frequently asked questions
Can you recover a database that DBCC CHECKDB says is unrepairable?
Yes, in most cases — and this is one of the most common things we see. DBCC's repair is one specific algorithm; when it gives up, that does not mean the data is gone. Page-level extraction tools work against MDF files that DBCC has refused, recovering tables and rows directly from the data pages. The recovery is usually less complete than a healthy database, but typically recovers 90%+ of user data in the cases we see. We give an honest estimate after a free initial assessment of the MDF.
Should I run DBCC CHECKDB REPAIR_ALLOW_DATA_LOSS?
Only after taking a forensic copy of the MDF and LDF first. REPAIR_ALLOW_DATA_LOSS can fix the database; it can also discard data. If you have a recent verified backup and the database is reproducible from it, the repair is a reasonable last-resort gamble. If the database has data that is not in any backup, take the forensic copy first — that way if the repair discards what you needed, we can still recover from the pre-repair state.
How long does SQL Server recovery take?
Most cases are 2–5 working days from receipt of the files. Complex cases — heavily corrupted MDF, multiple filegroups, large databases above 500GB — run 5–10 days. Emergency 24/48-hour service is available for business-critical recoveries; we routinely turn around mid-size SQL recoveries within a working day when the situation justifies it. Triage and quotation is always free.
Can you recover from just the MDF without the LDF?
Yes — in fact this is common. The LDF is often the file that gets damaged or lost first, especially in disk failure scenarios. Page-level recovery against the MDF alone produces a database that has lost any transactions still pending in the log at time of failure, but recovers the bulk of the committed data. We will tell you exactly what the implications are for your case after assessing the files.
Do you handle SQL Server inside Hyper-V or VMware VHDX/VMDK files?
Yes. We handle the virtualisation layer first — extracting the VHDX or VMDK, recovering the host NTFS/ReFS, locating the SQL data files within it — then move to SQL Server recovery on the extracted MDF. Many of the enterprise SQL Server cases we see come in via Hyper-V or VMware recoveries; we treat it as a single multi-layer job rather than two separate engagements.
How much does SQL Server recovery cost in the UK?
Cost depends on database size, the failure mode, whether underlying storage recovery is needed first, and the recovery objective. Most mid-market SQL recoveries fall between £950 and £3,500 including VAT. Larger databases, multi-tier recoveries (storage + SQL), and emergency turnarounds are quoted individually. We give a fixed-price quote after free diagnosis. No fee if we cannot recover useful amounts of data.