Logical problem or physical media failure
If the disk reports I/O errors, disconnects, disappears or causes system freezes, treat the storage as unstable. Database repair should wait until the storage layer is secured and copied.
What not to do when SQL will not start
- Do not run DBCC repair options on the only copy.
- Do not overwrite MDF/LDF files with an untested backup.
- Do not detach, attach or move files repeatedly without preserving originals.
- Do not rebuild the server before collecting logs and file timestamps.
- Do not let automatic cleanup remove transaction logs that may still matter.
How to secure the environment
- Copy MDF, NDF and LDF files from a stable source if possible.
- Export SQL Server and Windows event logs.
- Record drive letters, mount points and storage layout.
- Preserve backups separately from the failed environment.
- Define which database, tables or period are business-critical.
Backups, logs and a test environment
A backup should be tested on a separate environment before it replaces the failed production state. If backups are inconsistent, older or incomplete, the original files may still be needed for recovery.
Good B2B path
Stop writes, secure copies, verify backup integrity, assess storage health and only then choose database repair, file extraction or full media recovery.
Related paths
FAQ
Should I run DBCC CHECKDB repair immediately?
Not on the only copy after a storage failure. First secure database files, logs and backups, then work in a test environment.
Does a backup solve the incident automatically?
Only if it is current, complete and restorable. Keep the failed database state until the restore path is verified.
Need a safe next step?
Tell us what happened, what was tried and which data matters most. We will suggest the safest diagnostic route before recovery work begins.
Request an initial assessment or call 573 532 490.