SQL Server Repair & Recovery

Database frozen, corrupt or worse? All is not lost — if there’s a way out of it, we’ll find it. Ring ☎

In most cases a database can be repaired back to an attachable state. Where it can’t, we recover as many tables and records as possible and merge them into a clean database your front end will work with, so people can carry on while we sort the rest.

SQL Server since 1999. You’ll speak to someone who has seen your error before.

Before you ring: three things not to do

[IMG-1] — The highest-value image on this page. A real SQL Server error: a database showing SUSPECT or RECOVERY_PENDING in Object Explorer, or a DBCC CHECKDB consistency error in the log. Redacted. It’s what the reader is staring at.
Alt: SQL Server database in suspect state

1. Don’t detach the database. This is the one that turns a recoverable problem into a disaster. A suspect database that gets detached often cannot be reattached, and you lose the options you still had.

2. Don’t restart the SQL Server service. It rarely helps and it can start a recovery you’re then unable to stop.

3. Don’t run REPAIR_ALLOW_DATA_LOSS. It’s named honestly. It will get the database online by deleting whatever it can’t fix, and you won’t get a list of what went. It’s a last resort, not a first step.

Do take a copy of whatever you can — a backup if the database will let you take one, or the MDF and LDF files if the service is stopped. Then ring us and read out the error.

What we deal with

• Databases showing SUSPECT, RECOVERY_PENDING or EMERGENCY
• DBCC CHECKDB consistency errors, allocation errors and torn pages
• Databases that won’t come online after a restart or a failover
• Restores that fail, and backup chains that turn out to be broken
• Transaction logs full, corrupt, or growing until the disk filled
• System database corruption — master, msdb, model
• MDF files with no matching log file
• Storage or controller failures that took the database with them
• Ransomware, which increasingly means the backups too
• Data deleted or overwritten by mistake, and the “who ran that UPDATE without a WHERE clause” phone call

Restore first, repair last

The first question we ask is whether you have a backup, because restoring a good backup beats repairing a damaged database every time. Repair, by definition, means accepting losses. A restore doesn’t.

So the order of work is:

1. Establish what’s actually damaged — usually one table, one index or a handful of pages rather than the whole database
2. Check what the backups can give us. Often a page-level or filegroup restore recovers the damage with no downtime at all and nobody outside IT ever knows
3. Repair in place where that’s genuinely the best option, and only after you understand what it costs
4. Extract and rebuild where the file structure itself is gone — reading the data out and rebuilding around what comes back

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

You get back a working database with the application attached to it, plus a straight account of what was recovered and anything that wasn’t. If something isn’t coming back, you’ll hear it early rather than at the end.

Why it happened, and stopping it again

Corruption isn’t random. The usual causes:

• Storage. Failing disks, controller problems, or a SAN doing something it shouldn’t. SQL Server usually detects it before the hardware reports it.
• Unexpected shutdowns mid-write — power, a host restart, a VM snapshot taken the wrong way
• Antivirus scanning the data files while SQL Server has them open
• DBCC CHECKDB never running, so corruption sits there for months getting backed up nightly
• Backups nobody has restored. A backup you haven’t tested is a hope, not a backup.
• Ransomware, which goes for the backup server first

Once you’re back up, a health check will tell you which of those applies and whether your backups would survive it next time — including the restore testing most people have never done → SQL Server health check

If it’s not corruption

Server down, database offline, everyone stopped? Ring rather than email →emergency SQL Server support

Errors, faults or something broken since a change → SQL Server support and consultancy

Recovery on Access, MySQL or a bespoke system → database recovery and data rescue · Access repair and recovery