Databases fail loudly and specifically, and the error the engine returns narrows the fault quickly. The part that separates this from ordinary file recovery comes afterwards: getting the file back is often the easy half, and getting the engine to mount and accept it is the half that takes the work. A recovered MDF or EDB that will not attach is not a recovery, and we do not treat it as one.
$ cdr diagnose /dev/db → Database: SQL Server · MDF · 220 GB → Status: SUSPECT — log damaged, will not mount → Client: confidential · Cambridge CB2 $ cdr engineer-working → MDF + LDF: copied read-only → Pages: repaired · checksums fixed → Database: online · tables intact $ cdr verify → ✓ tables — 220 GB → ✓ records — all back → ✓ database recovered — data back
This is what separates database work from ordinary file recovery, and it is where most of the effort actually goes.
Anybody can extract an MDF or an EDB from a damaged volume. The file comes back, it has the right size, it looks entirely plausible. Then the engine refuses to attach it, or attaches it and reports the database as suspect, and you are no better off than before.
Databases are internally structured in ways that must be self-consistent. Page headers, allocation maps, transaction logs and the dictionary describing the schema all reference one another, and damage to any of them can leave a file that exists but cannot be opened. Real recovery means repairing that internal consistency until the engine accepts the file, and then verifying it does by mounting it here before anything is returned.
We do not consider a database job finished until the database opens.
The engine found something inconsistent at start-up and stopped rather than risk making it worse. Frequently resolvable from the transaction log without any file repair at all.
The store was not closed cleanly and the logs have not been replayed. Where the log files survive this often resolves through replay rather than through recovery work.
InnoDB cannot reconcile a per-table file with the dictionary describing it. Orphaned .ibd files are recoverable but need the schema reconstructing around them.
The file is present and the engine will not take it. Header damage, page corruption or a mismatched log. This is the class where extraction alone achieves nothing.
The fenland food industry runs on traceability. Batch, provenance and cold-chain records sit in SQL and in a surprising number of ageing bespoke systems, and a grower or packer who cannot produce them for an audit loses the contract rather than merely the data. Those jobs arrive with a fixed external deadline and no possibility of extension.
The second stream is professional — case management and land records from practices in Bury St Edmunds, Chelmsford and Cambridge, frequently subject to disclosure obligations that make the recovery an evidential matter as much as a technical one. The third is research: experimental and instrument databases from the university and the science parks, often in formats the original software can no longer open even once the file is back.
Stop the service before copying anything. Copying a live database file while the engine is running produces an inconsistent copy that will not attach. Stop the service, then copy — or leave it entirely and let us take the volume.
Database recovery starts at £500 +VAT. Where the database sits on a failed array, the array reconstruction and the database repair are quoted together as one figure rather than billed as two jobs.
Verification is included. A database is not returned until it has been mounted here and confirmed to open, because a file that will not attach is not something worth paying for.
Rarely. Suspect means the engine found an inconsistency and stopped rather than risk compounding it. Where the transaction log survives, a great deal is usually recoverable. Do not run repair with data loss allowed as a first move.
Usually a dirty shutdown rather than damage. If the log files are present the store can often be brought to a clean state by replaying them. Preserve every log file — deleting logs to free space is what turns this into a real recovery job.
Yes, and that is the common case. The array is reconstructed first, the database files extracted, then repaired until they mount. It is quoted as one job rather than two.
Recoverable, but the schema has to be reconstructed around them because InnoDB stores table structure separately from the data. Send anything else that survived — a dump, a backup, an old copy of the schema all shorten the work.
A seasonal pattern here. Sage files have fixed structures that recover predictably once the underlying volume is readable. Tell us the deadline at the first call and we will say honestly whether it is achievable.
Yes. It is mounted here and confirmed to open before anything is returned. That verification is the difference between a file and a recovery, and it is included rather than extra.
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.