Specialist · database recovery
A database that won't attach isn't recovered — it's retrieved. SQL Server and Exchange both keep strict internal consistency, and the built-in 'repair' switches buy silence by discarding your data. Our sequence is fixed: forensic copies of every file first, then engine-level work on the copies, never the originals.
Talk it through with an engineer
01273 964902
| The situation | What it means | First move |
|---|---|---|
| SQL database marked Suspect | The log couldn't replay cleanly after an unclean shutdown | Copy MDF+LDF before anything |
| Recovery Pending that never completes | Startup recovery stalled — often a storage fault beneath | Check the layer below too |
| Errors 823 / 824 / torn page | The engine caught corrupt pages on read | Stop the retries — image |
| Error 5171: not a primary database file | Header damage on the MDF | Header repair on the copy |
| Exchange: Dirty Shutdown state | Logs weren't fully replayed into the EDB | Header check first, gently |
| Someone already ran the emergency repair | REPAIR_ALLOW_DATA_LOSS did what it says | Send it anyway — honestly |
Your device is logged with its own case reference the moment it arrives. An engineer assesses the fault, confirms what's actually recoverable, and you get a fixed price in writing — no diagnosis fee, no obligation, and no paid work until you say go.
Data files, log files and any backups are imaged read-only — including from failed storage, where the server and RAID playbooks run first to produce clean source images.
On the copies: headers repaired, logs replayed where they're usable, and where they aren't, data extracted directly from the file's internal pages — tables, mailboxes, attachments — with specialist tooling.
The result is brought to a state the engine genuinely accepts — attached, mounted, queried — and verified against what you told us matters before anything is signed off.
Before you pay the recovery fee you approve a full listing of what came back. Your data returns on new media with free return postage, and the case only closes once you've confirmed everything opens on your side.
The distinction this whole page turns on: file recovery ends when the bytes are back; database recovery ends when the engine attaches, mounts and answers queries. The gap between those two finish lines is where consistency lives — and it's why a recovered MDF from a generic lab so often arrives here next, still refusing to attach.
Power cut overnight, Suspect by morning, and an IT contractor's finger hovering over the emergency repair. Forensic copies first told a better story: the log was intact enough to replay. Recovered on the copy, attached clean, and the morning's appointments ran twenty minutes late instead of a week.
Nothing clever: take it offline and secure copies of the MDF and LDF before any tool runs. Suspect means the engine couldn't cleanly replay its log after an unclean shutdown — frequently very recoverable, and most of the ways it becomes unrecoverable involve well-meant repair commands run on the original.
Often, yes. The data file holds the substance, and it can usually be brought to an attachable state without the log — the honest cost is that transactions in flight at the failure may be incomplete. We'll tell you exactly where that boundary landed in your case.
Usually not. Dirty Shutdown means outstanding logs weren't replayed into the database — the gentle header check names which ones, and soft recovery replays them where they survive. The mail is typically all there; the hard-repair shortcut is what puts it at risk.
Because the database was never the patient — the storage underneath is. Recurring corruption almost always means a failing drive, a degraded array or a cache problem writing fresh damage into every 'fixed' copy. That's a server-recovery case with a database symptom, and we treat it as both.
Every restart of a damaged device costs data. Open a case first — the diagnosis is free either way.