Databases fail loudly and specifically, and the message the engine gives you narrows the fault fast. What follows is the part that separates this from ordinary file recovery: getting the file back is straightforward, getting the engine to accept it afterwards is the actual job.
$ mdr diagnose /dev/db → Database: SQL Server · MDF · 220 GB → Status: SUSPECT — log damaged, will not mount → Client: confidential · Manchester M2 $ mdr engineer-working → MDF + LDF: copied read-only → Pages: repaired · checksums fixed → Database: online · tables intact $ mdr 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 loudly and specifically, which is more helpful than it feels at the time.
Pulling the file off failed storage is conventional recovery. Making the engine accept it is not.
An engine expects internal consistency: page checksums that match, allocation maps that agree with what is allocated, index structures that point at real rows, log sequence numbers in order. A file assembled from a damaged volume frequently fails those checks even when almost every byte is present — and that is the gap this work closes.
Pages are validated, damaged ones identified and mapped back to the tables and records they belong to, and structures repaired until the database mounts. Where a page cannot be recovered, you are told which objects are affected rather than handed a store that fails on attach. Where the file cannot be brought online at all, records can usually be extracted directly from the pages and exported as usable data — not elegant, but far better than nothing.
Including the small databases that turn out to be business-critical.
Microsoft SQL Server — MDF, NDF and LDF files, suspect databases, page-level corruption across all recent versions. MySQL and MariaDB — InnoDB and MyISAM, including IBD files recovered without their original tablespace. PostgreSQL and Oracle — cluster and tablespace files, including instances that will no longer start.
Microsoft Exchange — EDB stores and transaction logs, with individual mailbox extraction where the store cannot be mounted at all. And Access, SQLite and embedded databases sitting inside line-of-business applications, which are regularly the ones nobody realised the company depended on until they stopped opening.
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 and a 50% deposit applies with the balance on success.
Tell us the engine and version, the approximate size, and the exact wording of the error when it fails to mount — that message alone frequently identifies the fault class before the files arrive. NDAs are standard and invoicing is available.
Get the database files to us, and tell us the engine, version and what happened. The diagnostic that follows costs nothing, and one figure goes in writing before any work begins.
Nothing starts until the database files — or the failed storage holding them — to us is on the bench. Pack it properly and put your contact details in with it. Tell us the engine and version. The diagnostic that follows costs nothing, and one figure goes in writing before any work begins.
Posting it? Use something tracked and insured — whatever is on the drive is worth considerably more than the postage. Bringing it in? Weekdays, 9am to 5:30pm, and it still wants packing as above for the journey.
Not sure it is worth sending? Tell us about the database engine, files and fault, plus anything already attempted — an engineer reads every one of these and comes back with an honest view of the odds and a price band, before you post anything.
We’ll be in touch shortly. If it’s urgent, call 0161 871 0788.
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 automatic recovery. 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 will be incomplete, and we identify which objects are affected.
Damage to individual pages inside the database file, typically from bad sectors or an interrupted write. The engine refuses to attach or reports consistency errors on specific objects, and those pages are mapped back to the tables and rows they belong to.
Yes. A dirty shutdown where logs and database disagree is common and usually recoverable, with individual mailbox extraction available where the store cannot be mounted at all. Avoid running repair commands first — they can make it permanent.
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 until it mounts.
From £500 plus VAT, fixed in writing after a free 48-hour diagnostic. Where the underlying storage needs physical work too, that is quoted alongside with a 50% deposit and the balance on success.
A byte-complete database file is not a recovered database — one captured mid-transaction will attach and then fail. These are checked page by page for structural consistency before anything is handed back.
Quoted after the diagnostic, with a 50% deposit and the balance on success. A database that copies cleanly can still refuse to attach, so these are checked for structural consistency page by page rather than handed back on the strength of a file size.