SQL Database Corruption After a Power Failure: What to Protect First
After a power failure, SQL Server may report corruption even though the interruption began below the database. Controller cache, RAID parity, filesystem metadata, database pages, and the transaction log may represent different points in time.
Do not run repair against the only database files or restore onto the affected storage. Preserve the volume, database files, logs, and storage history before another write changes them.
What this condition means
An abrupt shutdown can interrupt writes at more than one layer. A database consistency error may reflect damaged SQL structures, incomplete storage writes, an unstable member, or a reconstructed volume that is not the same state SQL Server used before the outage.
The storage and database questions must be separated. Repairing SQL cannot correct an array assembled from the wrong member state, and rebuilding an array cannot repair database pages that were already incomplete.
What to record
- Exact SQL Server and operating-system errors
- Database platform, version, size, and recovery model
- MDF, NDF, LDF, backup, and application file locations
- Server, controller, RAID, SAN, NAS, or virtual-disk configuration
- UPS, power, cache, rebuild, filesystem, restore, and repair events
What not to do
- Run repair with data-loss options on the only copy
- Delete or rebuild the transaction log by trial and error
- Restore backups onto the affected volume
- Run filesystem repair before the storage is protected
- Assume the first database that attaches is complete
How ADR evaluates it
ADR establishes whether the underlying storage and database files can be read consistently. Unstable media is protected and the storage path is reconstructed before database-level work begins.
Database evaluation proceeds from protected copies. The objective may be a consistent database, selected tables, or priority records, depending on which structures and business data remain intact.
ADR can preserve the affected volume and database files, determine whether the RAID or filesystem changed during the outage, and then evaluate SQL structures from protected copies instead of repairing across uncertain storage.
What happens next
Power-loss corruption does not have one standard repair. The outcome depends on the storage state, readable database pages, available logs and backups, and what was written after the event.