A database is the one file a business truly can’t work without — and it’s also the one most likely to break in a way that stops everything. A crash mid-write, a full disk, a storage failure, a botched query: any of them can leave a SQL, Exchange or MySQL database that won’t mount, even though almost all of your records are still intact inside it. We repair and recover corrupt databases of every kind for businesses across the UK, with priority handling and NDAs as standard.
A database that won’t start usually has its records intact — it’s the structure around them that’s damaged, and that can be repaired.
An ordinary file can be a bit corrupt and still mostly usable. A database can’t — and that’s what makes it feel so catastrophic when it fails. A database is a tightly structured store of pages, indexes, allocation maps and transaction logs, all of which have to be internally consistent for the engine to open it. Damage a few critical pages — through a crash mid-write, a power cut, a full disk, or a storage failure underneath — and the whole database can refuse to mount, or drop into a ‘suspect’ state, even though the overwhelming majority of your actual records are sitting there perfectly intact.
That’s the reassuring part: ‘won’t mount’ almost never means ‘gone’. Recovery is a matter of repairing the structure — the pages and links the engine trips over — at a low level, and extracting the tables, records and mailboxes into a clean, consistent, mountable state. It’s precise, engine-specific work, but the data is usually very much still there.
Won’t mount, or ‘suspect’ / ‘recovery pending’. The database refuses to come online after a crash or an unclean shutdown — usually a consistency problem the engine won’t start past, with the data intact behind it.
Torn or corrupt pages. A power loss or storage failure mid-write leaves individual pages half-written or checksum-failing, and the engine flags corruption — repairable at the page level.
A missing, full or corrupt transaction log. A deleted or damaged log file (an LDF on SQL Server), or a log that filled the disk, can stop a database mounting even when the data file is fine.
Deleted records, a dropped table, or a mistaken query. An accidental DELETE, TRUNCATE or DROP, or an UPDATE with no WHERE clause — often recoverable from the data file or logs if caught before it’s overwritten.
Ransomware. An encrypted database file — recoverable in some cases from backups, earlier copies or remnants, and always worth assessing before anything is wiped (see ransomware recovery).
Storage failure underneath. The database is fine but the RAID, server or VM it lives on has failed — recovered by reconstructing the storage first, then the database.
The built-in ‘fix it’ commands are where a lot of recoverable data is lost. Before you reach for them:
Don’t run a repair that allows data loss (such as SQL Server’s REPAIR_ALLOW_DATA_LOSS) as a first move — it can discard the very pages and records that could have been recovered, and it can’t be undone. Don’t detach a suspect database; a database in a bad state may refuse to reattach, turning a recoverable situation into a much harder one. Don’t restore a backup over the original corrupt file until it’s been copied — you may need the original, and an old backup may not hold recent data. And don’t keep the application writing to a corrupt database. Take a copy of the data and log files exactly as they are, stop, and have them assessed — the original is your best starting point.
We work on a copy of the data and log files, never the live database, so nothing we do can make the original worse. From there we analyse the corruption at a low level — the damaged pages, broken index and allocation structures, and log inconsistencies the engine won’t start past — and repair or rebuild them to bring the database to a consistent state. Where a repair isn’t possible in place, we extract the data directly from the pages: tables, rows, schema and, for Exchange, individual mailboxes and messages, recovered into a clean database or an exportable form. Where the storage underneath failed, we reconstruct that first. The goal is always a mountable, usable database with as much of your data intact as the damage allows — and an honest account of anything that couldn’t be saved.
We recover the major database systems — Microsoft SQL Server (MDF, NDF and LDF files), MySQL and MariaDB (InnoDB and MyISAM), Microsoft Exchange (EDB stores and mailboxes), Oracle, PostgreSQL, Microsoft Access and SQLite — whether they’re running on a physical server, inside a virtual machine, or on cloud storage. Corrupt, suspect, dropped, deleted or trapped behind failed storage — if it’s a database, we can work to recover it.
It starts with a free assessment: we examine a copy of the database, establish what can be repaired and extracted, and give you a fixed written quote before any chargeable work. Because a downed database usually means a stopped business, a priority and emergency service is available, with NDAs and confidential handling as standard. Pricing is per case, reflecting the corruption and the engine involved. You can send us the database files securely or we can work from the storage — for businesses right across the UK and Ireland.
Usually, yes. A database marked suspect or recovery-pending has hit a consistency problem the engine won’t start past — but your records are almost always intact behind it. We work on a copy, repair the damaged pages and structures at a low level, and bring the database back to a consistent, mountable state, or extract the data directly. Avoid running a repair-with-data-loss yourself first, as it can discard recoverable records.
Not as a first step. That command lets SQL Server bring the database online by discarding whatever it can’t repair — which can permanently throw away pages and records that could otherwise have been recovered, and it can’t be undone. Take a copy of the data and log files as they are and have them assessed before running any data-loss repair.
Often, yes. An accidental DROP, TRUNCATE or DELETE frequently leaves the data recoverable from the database file or the transaction log — provided you act before it’s overwritten. Stop writing to the database, take a copy of the data and log files as they stand, and get it assessed quickly; the sooner it’s captured, the better the outcome.
Yes. We recover corrupt Exchange EDB stores — repairing the database to a mountable state, or extracting individual mailboxes and messages into a usable form for import. Whether the whole store won’t mount or specific mailboxes are affected, the data is usually recoverable.
Sometimes — and it’s worth assessing before anything is wiped. Depending on the attack, we may be able to recover from backups, earlier copies, snapshots or unencrypted remnants. Don’t delete the encrypted files or wipe the server before it’s been assessed, as those routes can disappear. See our ransomware recovery page for more.
Yes. Our lab is in Belfast, but database recovery is often done from files you send us securely, or from the storage by courier, so we work with businesses right across the UK and Ireland. With NDAs and priority handling as standard, your location makes no difference to the service.
Take a copy of the database and log files exactly as they are, stop, and get in touch. We’ll assess what can be repaired and extracted, and give you an honest, fixed quote before any chargeable work — priority and emergency service available, NDA as standard.