SQL Server Database Stuck in RECOVERY PENDING or SUSPECT? What to Do First (and What Never to Do)

Your application starts throwing connection errors, someone opens SQL Server Management Studio, and the database shows up with a label nobody wants to see: RECOVERY PENDING or SUSPECT. The next ten minutes matter more than the original failure. In our field work, we’ve seen more data lost to the panic response than to the incident itself — restarts at the wrong moment, files deleted to “free up space”, even entire virtual machines removed and rebuilt.

This guide walks through what to do in the right order: identify the exact state, find the real cause, choose the least destructive fix — and the moves you should never make, no matter how urgent it feels.

Last verified: 19 October 2026. Checked against Microsoft Learn for database states, ALTER DATABASE, DBCC CHECKDB, KILL and Accelerated Database Recovery. Microsoft’s database states page covers SQL Server 2017 and later plus Azure SQL; Accelerated Database Recovery starts with SQL Server 2019. T-SQL tested on SQL Server 2025 (build 17.0.4055.5).

Start Here: Diagnostic Table for the First Ten Minutes

Match what you see in sys.databases and the SQL Server error log to the row below before you change anything.

Step 1: Identify the Exact Database State

Don’t rely on the icon in Object Explorer. Ask SQL Server directly — this query works even when the database itself can’t be opened:

SELECT name,
       state_desc,
       user_access_desc,
       is_read_only,
       recovery_model_desc,
       log_reuse_wait_desc
FROM sys.databases
WHERE state_desc <> 'ONLINE'
   OR name = N'YourDatabase';

state_desc tells you which situation you’re in. log_reuse_wait_desc is the column most people skip — and as you’ll see below, it often explains why the database got there in the first place.

Quick Decision Table: What Each State Means

The definitions above follow Microsoft’s database states documentation. The two states that bring people to this page are RECOVERY PENDING and SUSPECT, so let’s take them one at a time.

RECOVERY PENDING: The Data Is Fine, Something Around It Isn’t

This is the most misunderstood state — and the most recoverable. Microsoft’s own definition is explicit: the database isn’t damaged; SQL Server hit a resource-related error while trying to start recovery. Files may be missing or unreachable, or the system may not have what it needs to open them. Your job is to find that resource, not to “repair” the database.

Real causes we’ve seen in the field

• Missing file permissions after a service restart. The SQL Server service account had been changed (or folder permissions tightened) while the instance was running. Nothing broke — until the next restart, when the service could no longer open its own data and log files.
• A full disk, caused by replication. Replication had stopped delivering changes, so the transaction log couldn’t be reused and kept growing until the drive filled up. On the next startup there was no room to complete recovery. The giveaway was log_reuse_wait_desc = REPLICATION in the query above.
• Changed drive letters. A customer reassigned drive letters on the server. The database files were all still there — just not at the paths SQL Server had recorded for them.
• Storage reshuffled at the virtualization layer. VMware administrators changed the virtual disk / host bus configuration of the SQL Server VM, and at boot the disks came up under swapped drive letters. Data volume where the log volume should be, and vice versa.

Notice the pattern: in every case the database was intact. The fix was to put the environment back the way SQL Server expected it — not to run a single repair command.

How to diagnose and fix it

First, compare where SQL Server expects the files with what actually exists on disk:

SELECT type_desc,
       name AS logical_name,
       physical_name,
       state_desc
FROM sys.master_files
WHERE database_id = DB_ID(N'YourDatabase');

Then read what SQL Server said at startup. The error log almost always names the exact file and the operating system error (for example “access denied” or “the system cannot find the path specified”). If you’re new to reading it, our guide to SQL Server error logs covers the basics.

-- Current error log, filtered to messages that mention the database
EXEC sys.xp_readerrorlog 0, 1, N'YourDatabase';

Fix the underlying cause — free or extend the disk, restore the drive letter or mount point, grant the service account access to the folder — and then let SQL Server retry recovery:

ALTER DATABASE [YourDatabase] SET OFFLINE;
ALTER DATABASE [YourDatabase] SET ONLINE;

SUSPECT: Recovery Ran and Failed

SUSPECT means SQL Server tried to recover the database and couldn’t — at least the primary filegroup may be damaged. This is where careful order of operations protects your data.

1. Stop and copy the files. Before any repair attempt, take physical copies of every file that belongs to the database: .mdf, .ndf, .ldf, full-text catalogs and FILESTREAM folders. Microsoft lists this as a prerequisite for repair, and it’s what keeps every later option open.
2. Find the last known good backup. In the vast majority of cases, restoring from backup is the right answer — and the fastest one. Our step-by-step SQL Server restore guide walks through full, differential and log restores.
3. Use EMERGENCY mode to rescue data, not to “fix” it. A sysadmin can set the database to EMERGENCY, which makes it read-only for sysadmins only. This is useful for copying out critical tables that changed after your last backup.
4. Treat REPAIR_ALLOW_DATA_LOSS as the very last resort. According to Microsoft’s DBCC CHECKDB documentation, it can lose more data than restoring a good backup; when it rebuilds the transaction log there’s no full ACID guarantee, and you must validate constraints afterward with DBCC CHECKCONSTRAINTS.

When the backup isn’t enough

Sometimes the backup exists but doesn’t contain everything you need. We worked with a customer whose backups didn’t include their full-text indexes, and rebuilding them from scratch wasn’t an option within their downtime window. Instead of repairing the damaged database, our team created a placeholder database with a matching file layout, swapped in the original data files, and brought it online in a controlled way — recovering the full-text structures that a plain restore would have lost.

It worked because the team knew exactly which steps were safe at each point. Attempted without that experience, the same technique can turn a recoverable database into an unrecoverable one. We’ll publish the full story as a separate case study.

RESTORING and RECOVERING: Usually a Matter of Patience

RESTORING most often means a restore sequence was started but never finished WITH RECOVERY. If this is a one-off restore and all the backups you need are applied, finish it:

RESTORE DATABASE [YourDatabase] WITH RECOVERY;

RECOVERING means SQL Server is replaying and rolling back transactions after a restart or failover. The error log reports progress in phases and percentages (“Recovery of database … is 42% complete”). Large or long-running open transactions make this phase slow. On SQL Server 2019 and later, Accelerated Database Recovery can shorten it dramatically — worth enabling before you need it.

What Never to Do — Real Mistakes We’ve Cleaned Up

Every item on this list is something we’ve personally seen make an incident worse:

• Restarting after killing a long-running transaction. Killing a large transaction starts a rollback. Restarting the service doesn’t skip that work — recovery has to finish the rollback before the database opens, and now everything else waits too. Check progress with KILL <session_id> WITH STATUSONLY and let it finish.
• Restarting a replica that is catching up. A system administrator restarted a node in a replicated environment while it was synchronizing, and hours of progress went back to zero.
• Deleting the SQL Server virtual machine. Yes, really — more than once. “We’ll just rebuild it” removes the very files a recovery would have needed.
• Deleting the .ldf file to free space. The log is not a scratch file. Without it, a database that was perfectly recoverable can go straight to SUSPECT.
• Detaching a damaged database to “re-attach it cleanly”. Attaching requires a successful recovery — exactly what’s failing. A database you can’t attach is far harder to work with than one SQL Server still knows about.
• Changing settings you don’t fully understand. One customer set FILLFACTOR to 1, believing it meant “fill completely”. It means each page is left about 1% full — the indexes ballooned, and runaway file growth is exactly how a full disk, and a RECOVERY PENDING database, begins.
• Running repair before restore. If a good backup exists, restore it. Repair is for when no backup can help.
• Pasting a command from a forum or an AI chat. The suggestion may be right for someone’s environment. It doesn’t know your backups, your topology, or what’s at stake.

Official Behavior, Aryasoft Field Notes and Our Recommendation

We separate three things on purpose: what Microsoft documents, what we have seen on real incidents, and what we advise. Treat them differently.

How to Make Sure It Doesn’t Happen Again

• Run DBCC CHECKDB regularly, so corruption is found by a scheduled job instead of by your users.
• Test your backups by actually restoring them — a backup job that “succeeded” proves only that a file was written.
• Monitor free disk space and log_reuse_wait_desc, especially on replicated databases.
• Agree with your infrastructure team that storage, drive-letter and service-account changes on SQL Server hosts go through the DBA first.
• Read our deeper dive on SQL Server corruption to understand where damaged pages come from.

For a real example of disciplined recovery, see how we recovered from an accidental restore with a 1-minute RPO.

How Fast Aryasoft Responds

When a production database is down, response time is part of the fix. Customers on our SLA plan get a DBA working on the incident within 30 minutes during business hours and 2 hours outside business hours. Maintenance support customers get a response within 2 hours during business hours and 4 hours outside them.

Sources (Microsoft Learn)

Technical claims in this guide were checked against these primary sources on 19 October 2026. Microsoft can change documentation at any time, so re-check version-specific details before a production change.

• Database states
• ALTER DATABASE SET options (OFFLINE, ONLINE, EMERGENCY)
• DBCC CHECKDB (REPAIR_ALLOW_DATA_LOSS, emergency mode, CHECKCONSTRAINTS)
• KILL (WITH STATUSONLY)
• sys.databases (log_reuse_wait_desc)
• Accelerated database recovery