Database stuck in recovery pending
SQL Server cannot complete startup recovery after the storage went offline, returned incomplete data, or came back in a changed state.
Recovery-pending guidance →Database recovery
Recover business databases after RAID, storage, or server failure.
A database that will not attach, remains in recovery pending, or reports corruption may be showing damage from a lower storage layer. ADR protects and reconstructs the storage path before judging the database itself.
Record the database platform and version, server and storage layout, file locations, exact errors, backup state, and every repair or restore already attempted.
Storage-first diagnosisRAID through database files
Originals preservedWork from protected copies
Customer-retained custodyWhen the storage can be accessed safely
Business-data verificationTables, records, and priority data
Recognize the failure
The database error may be the last visible symptom—not the first failure.
Controller changes, incomplete rebuilds, unreadable sectors, filesystem damage, and interrupted writes can all surface later as an attach, recovery, consistency, or transaction-log problem.
Database will not attach
The engine rejects the database files after RAID reconstruction, file copying, controller replacement, or an unexpected shutdown.
Attach-failure guidance →Controller replacement changed the volume
The files are visible, but their contents or relationships no longer match what SQL Server expects after a storage configuration change.
Controller-change guidance →Power failure left SQL corruption
Interrupted writes may affect database pages, logs, filesystem metadata, RAID parity, or more than one layer at once.
Power-failure guidance →Transaction log and data file disagree
The database cannot establish a consistent recovery point because required log records, data pages, or file metadata are incomplete.
Log-versus-data-file guidance →Database must remain onsite
Custody, compliance, size, or downtime requirements make remote evaluation preferable when the storage is stable enough for controlled access.
Remote database recovery →A controlled recovery path
Protect the storage first. Recover the database from protected copies.
- 1
Establish the storage state
Review the controller, RAID, volume, filesystem, database files, error history, and prior repair attempts.
- 2
Protect original evidence
Image unstable media and preserve original database files before repair, extraction, or conversion.
- 3
Reconstruct and evaluate
Recover the storage foundation, then assess file headers, allocation, pages, logs, and internal database consistency.
- 4
Verify business records
Validate the priority tables, records, attachments, dates, and application data the organization actually needs.
Choose the recovery location and scope
The objective is usable business data—not merely a database that mounts.
A successful attach does not prove that priority tables and records are complete. ADR focuses verification on the business data at risk. In most stable logical cases, the work can begin while the client retains custody; unstable storage must be protected first.
Before another repair attempt
Describe the database error and the storage event that came before it.
ADR will determine whether the next step belongs at the RAID, filesystem, database-file, transaction-log, record-extraction, or application-validation layer.