A SQL Server database stuck in recovery pending usually has intact data. The state means SQL Server could not start its recovery process, almost always because it cannot reach a data or log file, not because the data is damaged. Read the SQL Server error log to find the blocked file, fix the access problem, then run ALTER DATABASE with SET ONLINE. If a file is genuinely corrupt or missing, restore from backup, and when there is no backup the Univik SQL Database Recovery tool reads the MDF directly to pull the data out.
Few messages stop a database administrator’s morning faster than a database sitting in Recovery Pending. The SQL Server database in recovery gives no error, the instance is up, every other database is fine, and this one shows a status that sounds like it is working on itself when it is doing nothing at all. The good news comes first. A database stuck in recovery mode is usually not damaged, the data is probably sitting there intact, and the job is to clear whatever blocked recovery rather than to rebuild anything.
Since 2013 we have built SQL recovery tools at Univik and pulled data out of hundreds of MDF files that would not come online. Most recovery pending cases never need a tool at all, they need the error log read correctly and one blocked file freed. The safe fixes run in a specific order for a reason, and the wrong first move is what turns a recovery pending scare, or a database stuck in recovering, into real loss. The more serious suspect state and the one point where a specialist tool earns its place both come later.
What Recovery Pending Actually Means
Every SQL Server database sits in exactly one state at a time, and Recovery Pending is state number three. When SQL Server starts a database, it runs a recovery process that rolls committed transactions forward and uncommitted ones back, which is how the database stays consistent after any restart. Recovery pending means that process could not even begin, because SQL Server hit a resource it needed and could not get to.
The word resource is the key to the whole problem. In nearly every case the blocked resource is a file, the primary MDF, a secondary NDF or the transaction log LDF, and the block is an access problem rather than damage. A drive came online slower than the SQL Server service after a reboot. A file permission changed. Another process, a backup agent or antivirus, holds a lock on the MDF. The transaction log went missing or filled its disk. In each of these the data itself is fine, sitting in a file SQL Server simply cannot open yet. Our guide to the MDF file format covers how these files relate if you want the background on MDF, NDF and LDF.
Recovery Pending, Recovering or Suspect
Three states get confused constantly, and telling them apart tells you how worried to be. The difference is where recovery stopped.
Confirm which one you are looking at instead of trusting the icon in Management Studio. Run this against the master database and read the state in plain text.
SELECT name, state_desc, recovery_model_desc
FROM sys.databases
WHERE name = N'YourDatabase';A result of RECOVERY_PENDING confirms the state this guide fixes. If it reads SUSPECT, the damage is more likely real, and our guide on fixing a suspect SQL Server database is the one to follow. If it reads RECOVERING, close the query and wait, since recovery is doing its job.
Diagnose the Cause Before You Touch Anything
This is the step the rushed guides skip, and skipping it is how a fixable database turns into one you restore from last week. Recovery pending has a cause, the error log names it, and the right fix depends entirely on what it says. Read first, act second.
Open the current SQL Server error log filtered to your database name.
EXEC sys.sp_readerrorlog 0, 1, N'YourDatabase';The log almost always names the real problem in plain language, a file it could not find, an operating system error opening the MDF, a permission failure or a full disk. An OS error 5 is access denied, a permission problem. An OS error 112 is a full disk. An OS error 2 or 3 means a file is missing from the path SQL Server expects, and an OS error 32 means another process holds the file open. Read the message and you know which fix below applies, rather than guessing. One permission note for recent versions. On SQL Server 2022 and later, running sp_readerrorlog needs the VIEW ANY ERROR LOG permission, where SQL Server 2019 and earlier used VIEW SERVER STATE. A permission error on the command is why.
How to Bring the Database Back Online
Work these in order. Each one matches a cause the error log names, and most recovery pending databases come back at the first or second step.
Fix the Access Problem, Then Restart Recovery
When the log points to a file access issue, fix that first. Confirm the MDF and LDF exist at their paths and the drive is online. When a drive simply came online later than SQL Server, confirming the disk is ready and restarting the SQL Server service is often all recovery needs. Grant the SQL Server service account full control of the folder if a permission changed. Clear a full disk. Kill the process locking the file if a backup or antivirus agent holds it. Then tell SQL Server to try recovery again.
ALTER DATABASE YourDatabase SET ONLINE;With the block gone, recovery runs and the database comes online. This clears the largest share of recovery pending cases, since the file was never damaged, only unreachable.
Rebuild a Missing or Damaged Log
When the log is the problem, missing, moved or corrupt, the database needs its log rebuilt. Set the database to emergency mode so it becomes readable, put it in single user mode, then run a repair that rebuilds the log.
ALTER DATABASE YourDatabase SET EMERGENCY;
ALTER DATABASE YourDatabase SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
DBCC CHECKDB (YourDatabase, REPAIR_ALLOW_DATA_LOSS);
ALTER DATABASE YourDatabase SET MULTI_USER;Read that REPAIR_ALLOW_DATA_LOSS line carefully, because the name is honest about what it does. It can discard data to make the database consistent, so it is not a first move. Our explainer on what REPAIR_ALLOW_DATA_LOSS really does covers the risk in full. If the log is simply missing and the database was shut down cleanly, attaching the MDF and letting SQL Server build a fresh log is the gentler route, covered in our guide on attaching an MDF without the LDF.
Turn Off AUTO_CLOSE
A database with AUTO_CLOSE set to on closes after the last user disconnects and reopens on the next request. On a busy database that constant open and close can leave it stuck between states, and turning the option off clears the cause. Set it in the database properties under Options, or run one command.
ALTER DATABASE YourDatabase SET AUTO_CLOSE OFF;Restore From Backup
If the error log points to genuine file corruption rather than an access block, a clean restore beats any repair. A recent backup brings the database back exactly as it was with nothing discarded, which is why the backup is always the first thing to reach for when the file itself is damaged. Restore the last good full backup, then any differential and log backups in sequence.
When There is No Good Backup
This is the corner the manual steps cannot help with, a genuinely corrupt file and no backup to fall back on. REPAIR_ALLOW_DATA_LOSS may discard the very rows you need, and there is nothing to restore. This is where reading the MDF directly earns its place.
The Univik SQL Database Recovery tool opens the MDF at the file level without attaching it to SQL Server, reads the tables, indexes and stored procedures straight from the pages, and exports what it finds or writes it back to a working SQL Server. Because it never runs SQL Server’s recovery, a file SQL Server refuses to mount can still give up its data. It reads MDF files from SQL Server 2000 through the current versions, and the free MDF Viewer shows you what is readable before you commit to anything. This is a salvage route for the no backup corner, not a replacement for the safe fixes above, which handle the ordinary recovery pending case without any tool.
When the Safe Fixes do Not Work
A warning worth stating plainly, because a lot of advice online gets it wrong. Setting a database to emergency mode and running REPAIR_ALLOW_DATA_LOSS is not the quick first fix it is often presented as. Emergency mode makes a database readable so you can copy data out, and the repair can permanently delete data to force consistency. On a recovery pending database, where the data is usually intact and only blocked, reaching for that command first can destroy data that a simple file fix would have saved whole.
The order that protects your data is the order in this guide. Diagnose from the error log. Fix the access problem and restart recovery. Restore from backup if the file is truly damaged. Only when none of those apply, a corrupt file with no backup, does a direct MDF read or a repair that can lose data come into play. Jumping to the last step first is how recoverable databases lose rows.
Stopping It From Happening Again
Recovery pending repeats when its cause goes unaddressed, and two patterns cause most repeats. Databases that land in recovery pending after every reboot usually have a drive that initialises slower than the SQL Server service, and setting the SQL Server service to Automatic (Delayed Start) gives the disks time to come online first. Databases that hit it under load ran their log disk out of space, so monitoring free space on the log volume and keeping the transaction log in check heads it off.
Two platform features help beyond the basics. Accelerated Database Recovery, available from SQL Server 2019 and improved in the releases since, makes crash recovery and long rollbacks far faster, which shortens the window a database spends recovering. It stays off by default on a local SQL Server and is always on in Azure SQL Database. And on an Always On availability group a secondary replica can show recovery pending after a synchronisation failure rather than a local file fault, the case Microsoft covers in its guide on recovery pending in availability groups, where resuming data movement is usually the fix.
Underneath both sits the same rule every one of these guides comes back to. Tested, current backups turn a corrupt file from a crisis into a ten minute restore. Our guide on recovering a SQL database without a backup exists because so many teams learn this the hard way, and the whole point of it is a situation you never want to be in.
Frequently Asked Questions
Is My Data Lost When a Database is in Recovery Pending?
Usually not. Recovery pending means SQL Server could not start recovery because a file was missing, locked or unreachable, not that the data is damaged. Once you clear the block, the database comes online with everything intact. Data loss becomes a risk only if the underlying file is genuinely corrupt, which the SQL Server error log will indicate.
How is Recovery Pending Different From Suspect?
The difference is where recovery stopped. Recovery pending means recovery could not start, blocked by a missing or inaccessible resource, and the data is usually fine. Suspect means recovery started and then failed, so at least the primary filegroup may be damaged. Suspect is the more serious state and more often needs a repair tool or a restore.
Can I Fix Recovery Pending Without Losing Data?
In most cases, yes. Read the SQL Server error log, fix the file access problem it names, then run ALTER DATABASE SET ONLINE to restart recovery. That resolves the majority of cases with nothing lost. Data loss enters the picture only with the REPAIR_ALLOW_DATA_LOSS command or a genuinely corrupt file, neither of which the typical recovery pending case needs.
Why does My Database Go Into Recovery Pending After Every Restart?
The drive holding the database files is coming online more slowly than the SQL Server service, so SQL Server tries to open the files before the disk is ready. Setting the SQL Server service to Automatic (Delayed Start) usually fixes it by giving the disks time to initialise first. A VM resize or a storage change can trigger the same race condition.
What does ALTER DATABASE SET ONLINE Do?
It tells SQL Server to attempt recovery again and bring the database online. Run it after you have cleared whatever blocked recovery, a fixed permission, a freed file lock or a restored file. On its own, without fixing the underlying cause first, it will not work, since SQL Server hits the same block and returns the database to recovery pending.
Can I Recover a Recovery Pending Database With No Backup and a Corrupt File?
Yes, though it moves outside the built in commands. When the file is corrupt and no backup exists, a tool that reads the MDF directly, such as Univik SQL Database Recovery, pulls the tables out at the file level without relying on SQL Server’s own recovery. It is a salvage route for exactly this corner, not a substitute for the safe fixes that handle an ordinary recovery pending database.
The Bottom Line
A SQL Server database stuck in recovery pending looks alarming and usually is not. The state means recovery could not start, the cause is almost always a file SQL Server cannot reach rather than data that is damaged, and the fix is to find the block in the error log and clear it. Read first, fix the access problem, restart recovery with SET ONLINE, and the database comes back whole.
Keep the tools that can lose data in their place at the end of the line. Restore from backup when a file is truly corrupt, and when there is no backup and the file will not mount, a direct MDF read salvages what SQL Server cannot. The command that can delete rows is the last resort, never the first, and following the order in this guide is what keeps a recovery pending scare from turning into real loss.