A production database that will not mount, an accounting system reporting corruption, or a server volume that has suddenly disappeared can stop an organisation in its tracks. This guide to database file recovery explains what to do before well-meaning repair attempts turn a recoverable incident into permanent loss.
Database recovery is not simply about restoring a file with a familiar extension. A database is a structured system of tables, indexes, transaction logs and metadata. Whether the affected system is Microsoft SQL Server, MySQL, PostgreSQL, Oracle, Access or a proprietary application database, the priority is to preserve the original evidence and prevent further writes.
First, stop the activity that can overwrite data
If the database is stored on a failing drive, RAID, NAS or virtual machine datastore, shut down the affected system in a controlled manner if it is safe to do so. Do not keep restarting it to see whether it will come back. Each restart can trigger disk activity, journal updates, RAID rebuild attempts or automatic repair routines that alter the very sectors needed for recovery.
If the database was deleted, avoid installing recovery software on the same drive. Deleted files are often still physically present until their storage blocks are reused. On an SSD, the risk is higher because TRIM can clear deleted blocks quickly and make recovery impossible. Disconnect the device where practical, record what happened, and preserve any error messages, screenshots and system logs.
For a business-critical incident, also pause scheduled jobs. Backup software, database maintenance plans, replication, synchronisation tools and antivirus scans may write to the affected storage. A clean timeline of events helps recovery engineers identify whether the issue began with software corruption, accidental deletion, failed storage hardware or an interrupted update.
Identify what has actually failed
The visible error is not always the root cause. A database can fail to open because its internal file structure is damaged, but it can also be completely healthy while the storage beneath it is failing. Treating a hardware fault as a software issue is a common and costly mistake.
Logical database corruption
Logical corruption affects the database files or their structures rather than the physical storage device. Typical causes include an abrupt power loss, operating system crash, failed database update, interrupted import, application bug or an incomplete backup restoration. You may see checksum errors, missing tables, invalid page errors, a database marked as suspect, or messages that prevent the service from starting.
Where the underlying drive is known to be healthy and there is a verified copy of the affected files, vendor repair utilities can sometimes be appropriate. They should be run only against a working copy, never the only original. Some repair functions restore access by removing damaged pages, records or indexes. That may be an acceptable trade-off for a non-critical test database. It is not automatically acceptable for financial records, legal evidence, customer data or operational systems where every transaction matters.
Physical storage failure
A database file may appear corrupt because its drive is unable to read it reliably. Warning signs include clicking or repeated spin-up sounds from a hard drive, a device that disappears from the system, very slow reads, I/O errors, RAID members dropping offline, or a NAS reporting degraded storage.
Do not run a file-system check, RAID rebuild or database repair while a drive is unstable. These processes place sustained stress on the device and can write changes across a complex storage layout. In a multi-disk array, the disk order, RAID configuration and condition of every member matter. One incorrect rebuild can overwrite parity information needed to reconstruct the database.
A practical guide to database file recovery
A safe recovery process begins with an assessment, not a repair command. The objective is to establish the condition of the storage media, identify the database technology and decide whether a logical copy can be made without increasing the risk.
A professional recovery workflow usually follows four stages:
- Preserve and assess: The original media is protected, its symptoms are documented and the likely failure type is established.
- Create a working copy: Where possible, engineers make a sector-level image or a controlled copy of the storage. Recovery work is performed on that copy, preserving the original.
- Reconstruct and validate: Database files, logs and supporting metadata are recovered or rebuilt. Tables, schemas, records and relationships are checked for consistency.
- Return usable data: The recovered database is supplied in an agreed format, such as native database files, exports, CSV files or a restored virtual machine image, subject to what the damage allows.
The distinction between recovering files and recovering usable records is vital. Finding an MDF, NDF, LDF, DB, SQL, ACCDB or similar file is only the first step. The recovered result must be examined for completeness, transaction consistency and readability in the intended application.
Why transaction logs and backups matter
Databases use logs to maintain consistency when transactions are interrupted. In SQL Server, for example, transaction log files may be essential to bringing data to a consistent point. MySQL installations may rely on binary logs, redo logs or table-specific files, depending on the engine and version. PostgreSQL uses write-ahead logs, while Oracle environments have their own archive and redo-log architecture.
Keep every related file, even if it appears old or unimportant. A detached database file, associated log, configuration file, backup catalogue or virtual disk snapshot can provide the missing context needed to recover more complete data. Do not rename, modify or open these items unnecessarily.
A backup is often the fastest route back to service, but it must be tested rather than assumed to be valid. Check when it was created, whether it completed, whether the required log chain exists, and whether it can be restored in an isolated environment. A backup that is three days old may restore the database, yet still leave a business with three days of orders, case notes or production records to account for.
Situations that require specialist intervention
DIY recovery has limits, especially when the database is commercially sensitive or the hardware is compromised. Specialist help is advisable when a database sits on a clicking hard drive, failed SSD, RAID, NAS, SAN, encrypted volume, damaged virtual machine host or CCTV storage system. It is also appropriate where repair tools report data loss, the only copy is involved, or the database contains regulated personal data.
Forensic-grade handling is particularly valuable for legal, insurance, corporate investigation and compliance matters. The aim is not merely to retrieve data but to maintain a clear, controlled record of how the media was received, assessed and processed. Confidentiality matters just as much for a family archive as it does for employee records or client databases.
Data Recovery Lab assesses failed storage and database incidents in a specialist London environment, with secure handling, clear findings and a no-recovery, no-fee approach. This is relevant when a conventional repair tool cannot read the source media safely, or when the value of complete and defensible recovery outweighs the risk of further experimentation.
Avoid these common mistakes
The most damaging action is continuing to use the affected storage. Beyond that, avoid reformatting a volume, accepting an automatic RAID rebuild without confirming the array state, reinstalling the operating system over the original disk, or saving recovered files back to the same device.
Be cautious with online advice that recommends a single command as a universal fix. A command that is harmless on a copied test file may write metadata changes to a live database or file system. Likewise, copying a database from a network share while the disk is failing can create an incomplete file that looks valid but contains unreadable sections.
If ransomware is suspected, isolate the affected system from the network but do not wipe it. Preserve ransom notes, encrypted examples, log files and backups. The original state may help establish the scope of the incident and improve the prospects of restoring clean data.
Plan the return to service
Recovery and business continuity are related but separate tasks. Once data has been recovered, restore it to clean, known-good storage and validate it before returning it to production. Check the database engine version, collation, permissions, linked applications and integrations. Test essential workflows, not just whether the database opens.
Then address the cause. Review backup frequency and retention, verify that restorations are tested, monitor disk health, protect servers with suitable power management, and document the RAID or storage configuration. The best recovery outcome is one that leaves the organisation less exposed than it was before the failure.
When the only copy of a critical database is inaccessible, restraint is often the most valuable first response. Preserve the media, preserve the related files, and make each next step one that improves your chances rather than reducing them.
