SQL Server Is in Recovery Pending and the Business Database Is Unavailable
SQL Server cannot begin startup recovery, and the production database the business needs is unavailable after a RAID, storage, controller, virtual-disk, filesystem, or power event. Protect the storage and database files before choosing a repair command.
Do not run repair with data loss, rebuild or delete the transaction log, or keep detaching and attaching the only MDF, NDF, and LDF files. Preserve the files and establish whether the underlying storage is trustworthy first.
Tell an ADR technician what the system reports and what has already been attempted. The failed system does not have to be brought online first.
What this condition means
Recovery Pending is a state, not a single diagnosis. Permissions, paths, or disk space can cause it without structural damage. This page addresses the crisis where the business database is unavailable and the files or storage may be damaged, unstable, or changed by an earlier recovery attempt.
SQL Server error logs and operating-system storage events help distinguish an engine-level problem from a storage problem. If the volume is degraded, intermittently available, unexpectedly rebuilt, or presenting read errors, SQL repair should wait until that layer and the original file set are protected.
What to record
- Complete SQL Server error-log messages and database state
- SQL Server version, database size, and recovery model
- Paths, sizes, and timestamps for every MDF, NDF, and LDF file
- Available backups and the last known successful backup or consistency check
- Windows, hypervisor, filesystem, controller, RAID, SAN, or NAS events
- Every attach, detach, repair, restore, rebuild-log, or storage action already attempted
What not to do
- Run emergency-mode repair on the only copy
- Delete, rename, or rebuild the transaction log by trial and error
- Repeatedly detach and attach the database
- Copy repaired files back over the originals
- Assume a healthy-looking RAID proves every database page is readable
How ADR evaluates it
ADR first determines whether the database files can be read consistently and whether the volume presenting them is trustworthy. Storage instability is addressed before database structures are modified.
Work then proceeds from protected copies. Depending on what remains intact, the recovery plan may target a transactionally consistent database, selected tables, or priority records rather than applying one automatic repair to every case.
ADR can begin by preserving the RAID or other source storage, protecting the MDF, NDF, and LDF files, and determining which layer is preventing recovery. The failed server and SQL instance do not have to start the database first. SQL-level repair is considered only after the original storage and file set have been preserved.
What happens next
Recovery Pending does not establish that the database is lost. Results depend on access to the files, the condition of the underlying storage, available logs and backups, and which database structures remain internally consistent.