Pulling an MDF or EDB file off a failed array is ordinary recovery. Getting the engine to accept it afterwards is not — internal consistency structures have to agree, and a file assembled from a damaged volume frequently fails those checks with almost every byte present. That gap is what this work closes.
$ bdr diagnose /dev/db → Database: SQL Server · MDF · 220 GB → Status: SUSPECT — log damaged, will not mount → Client: confidential · Oxford OX2 $ bdr engineer-working → MDF + LDF: copied read-only → Pages: repaired · checksums fixed → Database: online · tables intact $ bdr verify → ✓ tables — 220 GB → ✓ records — all back → ✓ database recovered — data back
A byte-perfect file can still refuse to attach if it was captured mid-transaction or has damaged pages in the wrong place. Getting the file back and getting a mountable database back are different results, and only one of them is useful.
Databases fail from underneath and from within, and the two need different work.
This is the whole reason database work is priced above ordinary file recovery.
Extracting an MDF, IBD or EDB file from a failed array is conventional recovery. Making it usable is not. The engine expects internal consistency — page checksums, allocation maps, index structures and log sequence numbers all agreeing — and a file assembled from a damaged volume frequently fails those checks even when almost every byte is present.
So the work continues past extraction: pages are validated, damaged ones identified and mapped to the tables and rows they belong to, and where a page cannot be recovered we tell you which objects are affected rather than returning a database that fails on attach. Where the file cannot be brought online at all, records can often be extracted directly from the pages and exported as usable data.
Including the mail stores that behave like databases.
MDF, NDF and LDF files, suspect databases, and page-level corruption across all recent versions.
InnoDB and MyISAM, including IBD files recovered without their original tablespace.
Cluster and tablespace files, including environments where the instance will no longer start.
EDB stores and transaction logs, plus individual mailbox extraction where the store cannot be mounted.
Smaller databases inside applications, which are frequently the ones nobody realised were business-critical.
Priced above file recovery because the work continues past extraction.
Database recovery starts from £500 +VAT, confirmed after a free 48-hour diagnostic. Where the underlying storage also needs physical work, that is quoted alongside it and a 50% deposit applies with the balance on success.
Tell us the engine and version, the approximate size, and what the error says when it fails to attach — that message alone often identifies the fault class before the files arrive. NDAs are standard and invoicing is available.
Send the database files in for a free diagnostic with the engine, version and what happened; an engineer assesses them and confirms the exact quote in writing before any work starts.
Getting your data back starts with getting the database files — or the failed storage holding them — to us. Send them safely, tell us the engine and version, and once we've run the free diagnostic we confirm your exact quote in writing before any work begins.
Posting it? A tracked, insured service is what we’d recommend. Rather drop it in? You’re welcome Monday to Friday, 9am to 5:30pm — just package the device up as above first.
Need a scoped quote first? Describe the database engine, files and fault on the form and an engineer will assess it and reply with a tailored quote.
We’ll be in touch shortly. If it’s urgent, call 01865 593000.
The questions we field most often about recovering databases.
Usually. Suspect means the engine could not bring it to a consistent state, often after a crash or a failed recovery attempt. The files are examined outside the engine, damaged pages identified, and the database repaired or its records extracted directly.
Often, yes. The data file holds the bulk of the content, and a database can frequently be brought online without its log — though transactions in flight at the moment of failure may be incomplete, and we identify which objects are affected.
Damage to individual pages within the database file, typically from bad sectors or an interrupted write. The engine refuses to attach or reports consistency errors on specific objects. Damaged pages are mapped to the tables and rows they belong to so you know exactly what is affected.
Yes — EDB stores and transaction logs, with individual mailbox extraction where the store cannot be mounted at all. Exchange behaves like a database and is handled the same way.
It is common after file-level recovery, and it is exactly what database work addresses. A byte-perfect file can still fail consistency checks, so the work continues past extraction to validate pages and repair structures until it mounts.
From £500 plus VAT, fixed in a written quote after a free 48-hour diagnostic. Where the underlying storage needs physical work as well, that is quoted alongside with a 50% deposit and the balance on success.
A free diagnostic, tiered pricing from £500, and no fix no fee on most jobs — every database engine covered, SQL Server, MySQL, Oracle and the rest, files and storage alike. Begin your recovery today.