Recover a SQL Server Database After a Power Failure
After an abrupt power loss, SQL Server may report recovery pending, suspect status, attach errors, or transaction-log damage. The visible database error can originate in the MDF or LDF files, the filesystem, the storage controller, or an underlying RAID that is no longer presenting consistent data.
Protect the storage and make copies of the database files before repair, log rebuilding, detach and attach attempts, or restore operations that write to the affected volume.
What this condition means
SQL Server uses the transaction log to bring committed changes forward and incomplete work back to a consistent state. A power interruption can expose incomplete writes, but it can also reveal storage damage that prevents the engine from reading otherwise valid pages.
The first job is to separate a database-level problem from a RAID, controller, filesystem, or media problem. Repairing the wrong layer first can discard evidence needed by the next one.
What to record
- Exact SQL Server error messages and database state
- SQL Server version, database size, and recovery model
- MDF, NDF, and LDF file locations and available backups
- Windows, controller, RAID, and storage event messages
- Repair, attach, restore, rebuild-log, or controller actions already attempted
What not to do
- Run repair with data loss on the only copy
- Delete or replace the transaction log by trial and error
- Repeatedly detach and attach the affected files
- Restore onto the same damaged storage as a test
- Treat a database error as proof the RAID is healthy
How ADR evaluates it
ADR first confirms that the storage beneath the database files is stable and coherent. When RAID or media damage is involved, that layer is protected and reconstructed before database repair.
Database structures are then evaluated from copies. The recovery plan can prioritize a consistent database, selected tables, or critical records according to what remains intact.
ADR can review the outage, storage state, SQL errors, and available MDF, NDF, LDF, and backup files before any repair is committed. That preserves the option to recover the full database or concentrate on priority business records.
What happens next
Many post-power-failure databases retain usable data, but the appropriate method depends on which storage and database structures can be read consistently.