Power Returned, but SQL Server Reports Corruption and the Business Application Will Not Start
The server may have restarted and the storage may appear online, yet SQL Server reports corruption, Recovery Pending, suspect status, attach errors, or a database the production application cannot use. The outage is no longer just a power event when the business records remain unavailable.
Stop repair, restore, log rebuilding, filesystem repair, and repeated restart attempts. Preserve the affected storage, every MDF, NDF, and LDF version, available backups, and the controller and power-event history.
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
An abrupt shutdown can interrupt writes or expose inconsistent states at several layers: controller cache, RAID parity, filesystem metadata, database pages, and the transaction log. Those layers may not all represent the same point in time when power returns.
The SQL message identifies where the engine stopped, not necessarily where the damage began. Repairing SQL cannot correct an array assembled from the wrong member state, and rebuilding the array cannot repair database pages that were already incomplete.
What to record
- Exact SQL Server, Windows, application, and storage errors
- Database version, size, recovery model, state, and last known working time
- Every MDF, NDF, LDF, backup, snapshot, and recovered copy
- Server, controller, RAID, SAN, NAS, virtual-disk, and cache configuration
- UPS events, power sequence, member status, rebuilds, filesystem checks, restores, and repairs
- The applications, tables, dates, and business records needed first
What not to do
- Run repair with data-loss options on the only database copy
- Delete or rebuild the transaction log by trial and error
- Restore a backup onto the affected storage
- Run filesystem repair before protecting the underlying volume
- Keep restarting the server or SQL service to see whether recovery completes
- Assume the first database that attaches contains the current, complete records
How ADR evaluates it
ADR establishes whether the underlying storage represents a stable and coherent state. Unstable members and affected volumes are protected before database-level work begins.
Database evaluation then proceeds from protected copies. Candidate results are tested against the tables, dates, relationships, and records the business requires—not merely whether SQL Server starts.
ADR can evaluate the outage history, storage state, file versions, SQL errors, and internal database structures in a controlled recovery environment. The objective is a defensible working database or the priority business records that remain recoverable.
What happens next
Power-loss corruption does not have one standard repair. The result depends on the storage state, readable and internally consistent database pages, available logs and backups, prior intervention, and which writes completed before and after the event.