Database Recovery & Data Rescue

When a business-critical database stops working, every minute matters.

Corruption, data that’s vanished, application errors, hardware failure, or an inherited system nobody fully understands — the priority is the same.

Ring ☎ and you’ll speak to someone who has done this before.

Before you do anything else

Stop using it. Every further write into a damaged database makes recovery harder and can overwrite the records still intact.

Take a copy and leave that copy alone. If you can take a backup, take one. If not, copy the files somewhere safe while the system is stopped. This is the single most useful thing you can do in the next five minutes.

Don’t run a repair tool on your only copy. Built-in repair options work often enough to be worth trying — but when they fail they can leave things worse, and some of them are honest enough to be called “allow data loss”.

Don’t detach a SQL Server database that’s showing as suspect. It often can’t be reattached, and that turns a recoverable problem into a permanent one.

Then ring us and tell us what the error says.

You haven’t lost a file, you’ve lost access to the business

Most organisations don’t just lose a database. They lose customer information, orders and transactions, operational records, financial data, the reports everyone relies on, and the processes built around all of it.

The database is usually at the centre of an application the business runs on every day, so recovering the file isn’t the job — restoring the business is.

We look at the whole system, not just the damaged part.

What we recover

Database corruption. Unexpected shutdowns, network drops, storage failures and software faults. We find the cause, recover what’s there and restore integrity where it’s possible.

Deleted, overwritten or missing data. Including the “who ran that update without a WHERE clause” phone call, which is more common than anyone admits.

Failed restores and broken backup chains. Often the real emergency — the database went, and then the backup turned out not to work.

Legacy system failure. Older databases and applications where understanding the architecture is most of the job before any recovery can start.

Systems that look like they’re failing but aren’t. Sometimes it’s performance, growth or a structural problem rather than damage — which is much better news, and worth establishing before anyone starts a recovery.

By technology

[IMG-1] — Recovery output: table-by-table record counts recovered, or a before/after reconciliation. Redacted. Proof this is methodical rather than a tool pointed at a file.
Alt: Database recovery, records recovered by table

Microsoft Access — corrupt ACCDB and MDB files, split database problems, front-end to back-end connection failures, network-related corruption, damaged forms, reports and queries. Where a file can’t be repaired outright, we recover what we can and merge it into a clean database your existing front end will open. → Access repair and recovery

SQL Server — suspect and recovery-pending databases, consistency errors, page and block corruption, restore failures, transaction log problems, system database damage. Where you have good backups, restoring beats repairing every time, and that’s the first thing we check. → SQL Server repair and recovery

MySQL — corruption, crashed tables, failed restores and recovery on systems behind web applications. → MySQL

Bespoke and inherited systems — where the database sits behind custom software that’s evolved over years, the original developer has gone and the documentation never existed. Understanding how it works is part of the recovery. → legacy software rescue

What we don’t do

Worth being clear, because “data recovery” means two different things.

If the hardware is physically dead — a drive that won’t spin up, fire or water damage, a snapped SSD — that’s a job for a specialist recovery lab with a clean room, not for us. Ring one of those first. Once they’ve got the files back, we can take it from there and rebuild the database around them.

What we do is recover data from databases: corrupt files, damaged structures, broken systems and failed restores, where the storage itself is readable but the database isn’t usable.

If you’re not sure which you’ve got, ring and describe it. That’s a two-minute conversation and it’ll save you calling the wrong people.

Ransomware

Increasingly the reason people ring, and it’s a different problem from corruption.

The database is usually intact and encrypted rather than damaged, which means the question isn’t “can this file be repaired” but “what’s the cleanest route back, and from when”.

We work with you and your IT people on what’s recoverable, what date you can realistically get back to, what was running between then and now that needs reconstructing, and getting a working system up somewhere clean.

The hard part is rarely technical. It’s that the backups were on a share the ransomware could also reach — which is why backup separation is the one thing we push hardest on afterwards.

How we work

We work on copies. The files you send us are never the ones we operate on.

First we establish what’s actually damaged — usually far less than it looks. Then we work through the recovery routes in the order that preserves most: restore from backup where one exists, repair in place, extract object by object, and where the structure itself is gone, reading the data out and rebuilding around what comes back.

You’ll get a straight account of what was recovered and anything that wasn’t, and you’ll hear about the things that aren’t coming back early rather than at the end.

Most jobs are dealt with over remote support, often the same day.

After the crisis

Recovery is usually the beginning.

Once you’re running again we can stabilise the application, document how the system actually works, sort out a backup strategy that would survive this happening again, fix the performance and structural problems that contributed, and put monitoring in so the next one gets noticed early.

The point isn’t getting it running. It’s making the next failure much less likely — and much less expensive when it happens.

SQL Server health check · Access health check

Planning, rather than panicking

Not everyone reading this has lost a database. Some of you are checking whether you would survive losing one.

That’s a better conversation to have, and a much cheaper one. We look at whether your backups restore — by restoring them, not by reading the job log — how long recovery would actually take, how much data you’d lose, whether the backups are somewhere ransomware can reach, and whether anyone has ever tested any of it.

Most businesses have never been given those numbers for their own systems. You’ll leave with them.

health check · database support

Case studies

all case studies