Specialist work · databases
A database that refuses to attach has been retrieved, not recovered. Both SQL Server and Exchange police their own internal consistency, and the built-in 'repair' options win that argument by throwing your data away. So the order here never varies: forensic images of every file, then engine-level work carried out on those images and never on what you sent us.
Speak to an engineer about it
0800 6890668
| The problem | What that tells you | First step |
|---|---|---|
| SQL Server database flagged Suspect | After a dirty shutdown, the log would not replay properly | Take copies of MDF and LDF first |
| Recovery Pending that simply sits there | Startup recovery has stalled — usually a disk problem underneath | Look at the storage as well |
| 823, 824 or torn-page errors | Bad pages were spotted as the engine read them | Halt the retries and image it |
| Error 5171: not a primary database file | The MDF header is damaged | Rebuild the header on a copy |
| Exchange sitting in Dirty Shutdown | Not every log made it into the EDB | Start with a gentle header read |
| A hard repair has already been attempted | REPAIR_ALLOW_DATA_LOSS behaved exactly as its name warns | Still worth sending in |
As soon as it lands with us, your device gets its own case number. An engineer works out the fault, says what can genuinely be pulled off, then puts one fixed price in writing — no charge for diagnosis, no obligation, and no chargeable work until you approve it.
Every data file, log and backup is copied read-only, failing storage included; on those, the server and RAID procedures come first so the sources we work from are clean images.
All of it on the copies: headers rebuilt, logs replayed when they can be, and when they can't, the file's internal pages read directly with specialist tooling to lift out tables, mailboxes and attachments.
We take the result to a point where the engine genuinely accepts it — attaching, mounting, answering queries — and check it against the things you told us mattered before anything is signed off.
You sign off a complete list of the recovered files first; only then does the recovery fee fall due. Everything returns on fresh media, postage paid, and the job stays open until you confirm the files open at your end.
The line this whole page rests on: file recovery is finished once the bytes exist again; database recovery is finished when the engine attaches, mounts and answers a query. Consistency lives in the space between those two points — which is why an MDF rescued by a general-purpose lab so often reaches us afterwards, still refusing to go back on.
The power went overnight; by morning the database sat in Suspect and an IT contractor was poised to run the emergency repair. Copies taken forensically told a kinder story — the log could still be replayed. Recovery ran on the copy, it attached cleanly, and the morning's bookings slipped twenty minutes rather than a week.
Keep it simple: pull it offline and copy the MDF and LDF somewhere safe before running anything. Suspect only means the engine failed to replay its log tidily after a dirty shutdown — often very recoverable, and the usual route to losing it for good is a well-meant repair command aimed at the original.
Usually, yes. Nearly all of the content sits in the data file, which can generally be coaxed into an attachable state with no log — the honest price is that transactions still open when it failed may be partial. We'll show you precisely where that line fell in your case.
Usually not. A Dirty Shutdown state means logs are still waiting to be replayed into the database — a harmless header check names them, and soft recovery replays whichever ones survive. The mail is normally all intact; it's the hard-repair shortcut that endangers it.
Because the database was never really the patient — the storage under it is. Corruption that keeps returning nearly always points to a dying disk, a degraded array or a cache fault stamping new damage into each 'repaired' copy. That is a server recovery wearing a database symptom, and we treat both.
Powering a damaged device up again costs you data. Start a case first; diagnosis is free whatever you decide.