SQL Server Emergency Recovery
SQL Server emergency recovery
SQL Server down, corrupted or encrypted? Get expert help now.
Suspect databases, corruption errors, failed restores, a SQL Server that won’t start, or a ransomware attack: every hour counts, and the wrong first step can make data loss permanent. Talk to a SQL Server internals expert before you try anything risky.
Call now: +1 (415) 590-6669 Request emergency recovery
Led by Andreas Wolter: former Microsoft Senior Program Manager for Data Platform Security, one of only seven Microsoft Certified Solutions Masters (MCSM): Data Platform, 25+ years of SQL Server experience.
We help when your database is corrupt, suspect or won’t come online
- A database is marked SUSPECT or stuck in RECOVERY PENDING.
- DBCC CHECKDB reports corruption, or the error log shows I/O errors such as 823, 824 or 825.
- Backups fail to restore, or the last good backup is too old.
- SQL Server won’t start after a crash, storage failure or patch.
- Ransomware has encrypted database or backup files.
- You need a forensic investigation after a breach: what was accessed, when and by whom.
While you wait for us: do this first
- Ransomware: isolate. Disconnect affected servers from the network, but do not wipe or rebuild them; preserve them for recovery and forensics, and involve your incident response team, insurer and legal counsel.
- Otherwise, keep everything as it is. Don’t stop services, move or copy database files, or attempt repairs unless an experienced professional guides you.
- Keep the evidence. Save the SQL Server error log, the Windows event logs and any DBCC CHECKDB output. Note the exact error numbers and messages.
- Find your last good backups. Identify the most recent full, differential and log backups, and do not overwrite backup media or rotate tapes.
And don’t do this
- Don’t run DBCC CHECKDB with REPAIR_ALLOW_DATA_LOSS as a first step. It can permanently delete data to make the database consistent. It is a last resort, not a fix.
- Don’t detach a suspect or damaged database. It may not attach again.
- Don’t delete or rebuild the transaction log. Removing the .ldf file can cause data loss and leave the database transactionally inconsistent.
- Don’t restore over the damaged database without keeping a copy of the original files.
- Don’t run third-party “repair” tools against your only copy.
How we work
- Triage call: we review the symptoms, errors and backup situation with you.
- Damage assessment: we determine what is recoverable and the safest path to get there.
- Recovery: we recover data that standard methods cannot reach, with the least possible data loss.
- Root cause and forensics: we find out what happened, so it doesn’t happen again, and support your investigation after a breach.
- Hardening: optional follow-up to close the gaps, from backup strategy to ransomware resilience and auditing.
Frequently asked questions
My SQL Server database is marked SUSPECT. What should I do?
Don’t detach the database, don’t restart SQL Server repeatedly, and don’t run DBCC CHECKDB with REPAIR_ALLOW_DATA_LOSS as a first step. Save the SQL Server error log and the Windows event logs, note the exact error numbers, and call us. The wrong first step can make data loss permanent.
Can you recover a corrupt SQL Server database?
Often, yes. We first find out what is damaged and why. Then we recover from your backups where possible, and repair only what must be repaired, so you lose as little data as possible.
What do DBCC CHECKDB errors mean?
DBCC CHECKDB found inconsistencies in the database, for example damaged pages or broken links between them. Errors 823, 824 and 825 in the error log point to problems reading from or writing to storage. Keep the full CHECKDB output: it tells an expert what can be recovered.
SQL Server won’t start, or a database won’t come online. Can you help?
Yes. Common causes are damaged system databases, missing or inaccessible files, storage failures or a failed patch. Save the error log and call us before you reinstall or rebuild anything.
A restore failed. What now?
Don’t overwrite backup media or rotate tapes. Keep every backup file you have. A failed restore doesn’t always mean the backup is lost: we check what can be read and recovered.