Skip to content

SQL Server Database Recovery: MDF and NDF File Recovery

AS provides SQL Server database recovery for databases that fail at the storage or page level, where most of the actual data usually survives intact. We parse the data and log files directly, independent of the SQL Server engine, before any repair command is considered.

Call +91 74187 05822 · WhatsApp us · Since 2018 · 656+ cases solved · Free assessment, no data no charge

Prefer to check it yourself first?

AS SQL Recovery & Repair Studio — Recover and repair damaged, corrupted and ransomware-encrypted SQL Server databases (MDF / NDF) — table by table, row by row.

When you need this

  • Database stuck in SUSPECT, RECOVERY_PENDING or EMERGENCY mode
  • Database stuck "In Recovery" for an unusually long time after a crash or restart
  • MDF/NDF files corrupted after a storage fault or unclean shutdown
  • Transaction log (LDF) corrupted or missing
  • Backup (.bak) file damaged or incomplete
  • tempdb corruption preventing the instance from starting
  • Always On Availability Group failover leaving a database in RESTORING state
  • TDE (Transparent Data Encryption) certificate lost or unavailable
  • Tables or rows deleted without a usable backup
  • Considering DBCC CHECKDB with REPAIR_ALLOW_DATA_LOSS

Our SQL database recovery services

File-level parsing

Our SQL Server database recovery reads MDF/NDF data files directly at the page level, without attaching to a SQL Server instance, to extract tables and records from files that won't mount.

Manual hex-level verification

SQL Server stores data in fixed 8KB pages, each starting with a 96-byte header that encodes the page ID, page type, object ID, index ID and LSN (log sequence number). When automated parsing hits a page whose header is ambiguous or partially overwritten, a technician inspects the raw bytes directly in a hex/disk editor to identify the true page boundaries and object linkage before deciding how to proceed — rather than letting an automated tool guess.

Transaction log recovery

LDF files are examined for recent, uncommitted or deleted changes where the space hasn't been overwritten.

.bak restoration

Damaged or partial backup files are analysed for the recoverable portion, rather than assuming the whole backup is unusable.

System database and instance-level issues

Where tempdb, model or msdb corruption prevents the instance from starting at all, we work at the instance/file level to get user databases accessible again independently of the broken system database.

Availability Group / clustering scenarios

Where a failover has left a replica in RESTORING or SUSPECT state, we assess the underlying data and log files directly rather than assuming the replica itself is unrecoverable.

Safer than REPAIR_ALLOW_DATA_LOSS

SQL Server's own repair option deletes corrupted pages rather than reconstructing them. We assess a file-level or backup recovery path first, since it can retrieve data that repair would simply discard.

A database data file as a sequence of fixed-size pages, with a byte-level view of a damaged page header next to an intact oneData file, read page by pageEach page has its own header (page ID, type, checksum/LSN) and contentintact page headerdamaged / encrypted pagesPage header, byte level (illustrative)intact page:4E000800010000003A91damaged page:0000????01000000FFFFPage type and checksum bytes don't match what's expected — a technician confirms this directly in ahex/disk editor before deciding whether the page is recoverable or needs to be skipped.Why this matters for recoveryA few unreadable pages don't make the rest of the file unreadable. Parsing the file directly, page bypage, recovers what's intact even when the database engine itself refuses to open the file at all.

MDF/NDF files are made of fixed 8KB pages, each with its own header — a damaged or unreadable page doesn't make the rest of the file unreadable.

See AS SQL Recovery & Repair Studio work

How to repair a corrupt SQL Server MDF file: free analysis and preview (2.5 minutes)

How it works

  1. Step 1

    Consultation and scope

    We establish what failed, what has been tried, and which data matters most. This shapes a targeted plan rather than a generic one.

  2. Step 2

    Secure imaging and diagnosis

    Where possible the source media is imaged before any work, so the original is never altered. Diagnosis then determines the safest recovery method.

  3. Step 3

    Recovery

    Data is extracted from the image or source using methods matched to the failure — logical, structural or hardware-level as required.

  4. Step 4

    Verification

    Recovered data is checked for integrity and completeness, and a file list is shared so you can confirm what matters is there.

  5. Step 5

    Secure delivery

    Verified data is returned through an agreed secure method, with guidance on validation before it goes back into production.

MDF and NDF recovery: what each file holds

A SQL Server database lives in one primary data file (.mdf), optional secondary data files (.ndf) and the transaction log (.ldf). MDF and NDF recovery work the same way: we read the 8 KB pages directly and rebuild the tables, whatever state SQL Server reports for the database.

MDF recovery

The MDF holds the system tables that describe every table and column, plus the data of the primary filegroup. From a corrupted, deleted, truncated or partly encrypted MDF we rebuild the schema and extract the rows that survive, into a new database or as scripts.

NDF recovery

NDF files hold the data of secondary filegroups, often the largest tables. We recover them together with the MDF. When the MDF itself is badly damaged, the table definitions can come from an older backup or another copy of the same application's database, and the NDF rows are read against them.

MDF without its NDF or LDF

A missing or damaged LDF does not stop the data being recovered from the MDF and NDF files. A missing NDF means the tables stored in that filegroup must first be found on the disk, but every table in the remaining files is still extracted.

Ransomware-encrypted MDF and NDF

Ransomware usually encrypts only parts of large data files. We map exactly which pages are encrypted and recover the rest: in one published case a 27.3 GB SQL Server 2008 R2 database encrypted by ransomware gave back 96.0 million rows from 222 tables.

SQL database recovery without a working backup

Most SQL database recovery cases reach us because the last backup is missing, old, damaged or encrypted too. Recovery from the data files does not depend on any of them.

Any SQL Server from 2008 to 2022

The version is read from each data file, so databases from SQL Server 2008, 2012, 2014, 2016, 2017, 2019 and 2022 are recovered the same way, whatever version is installed on the server today.

Every table and row checked

Every recovered row is checked against the page and table structure, and you get a row count for every table, so you know exactly what came back before the database goes into production.

Delivered ready to attach

Recovered data is delivered as a new database you can attach to your SQL Server, or as scripts and CSV files for the tables you need first.

What affects the outcome

We have solved 656+ cases like these. Every case is assessed on its own condition, and we tell you exactly what is recoverable after a free assessment, before you pay anything.

  • Physical condition of the media and the extent of any damage
  • Whether the media has been written to, reformatted or re-initialised since the failure
  • Encryption, corruption or partial overwriting of the data
  • Availability of source data such as images, backups, logs or transaction records
  • Attempts made before assessment (rebuilds, repair tools, repeated reboots)
Related AS software

AS SQL Recovery & Repair Studio

Open a damaged, corrupted or ransomware-encrypted MDF / NDFfile yourself. The free edition shows the damage map and previews the recoverable tables and rows, so you know what can come back before you pay for anything.

Frequently asked questions

Should I run DBCC CHECKDB with REPAIR_ALLOW_DATA_LOSS?

Not before a copy is taken and an assessment is done. That option deletes corrupted pages rather than recovering them, and can discard data that a file-level recovery could have retrieved.

Our database shows SUSPECT — is the data gone?

Usually not. SUSPECT typically means SQL Server can't safely bring the database online, not that the underlying pages are destroyed. An assessment determines what's actually recoverable.

The database has been stuck "In Recovery" for hours — is that normal?

Briefly, yes — SQL Server runs redo/undo on restart, which takes time proportional to how much uncommitted work was in flight. If it's been stuck far longer than expected, or the log itself is damaged, that's when a file-level assessment is worth doing rather than continuing to wait indefinitely.

Can you recover from just the .bak file if the live database is gone?

Often yes, and also from a damaged or partial backup — we analyse what portion of the backup is structurally intact rather than requiring a complete, healthy file.

We lost the TDE certificate — is an encrypted database unrecoverable?

This is one of the harder cases, since Transparent Data Encryption is designed specifically to make the data files unreadable without the certificate. Contact us for an honest assessment of your specific situation before assuming there's no path forward.

tempdb won't start and the whole instance is down — what now?

tempdb corruption is a system-level problem, not necessarily data loss in your actual databases. We work at the instance and file level to get user databases accessible again, independent of the broken system database.

Do you support SQL Server recovery for companies in Bangalore, Chennai, Hyderabad, Pune or Mumbai?

Yes. MDF/LDF and backup file recovery is done from images and files, not on-site on your server, so we work with businesses in these cities and across India remotely, with secure courier pickup for physical storage and on-site visits available for enterprise cases.

Can you recover an MSSQL database after a ransomware attack?

Yes. We have recovered many MSSQL databases after ransomware without the attacker's key. Large MDF, NDF and BAK files are usually only partly encrypted, so the tables are rebuilt from the 8 KB pages that survived and handed back as a clean database. Stop the SQL Server service, keep the encrypted files and contact us for a free assessment.

Do you do MDF file recovery and LDF file recovery?

Yes. MDF file recovery is the main case: the data file holds the tables, and we extract them from a corrupted, deleted or partly encrypted MDF or NDF. LDF file recovery matters when the transaction log holds changes that never reached the data file. A database can usually be recovered from the MDF alone when the LDF is missing or damaged.

Can you recover a SQL Server backup that will not restore?

Often. SQL Server backup recovery reads a damaged, truncated or partly encrypted .bak file directly and extracts the database pages that are still intact, including from compressed backups, instead of relying on RESTORE, which stops at the first error.

Call 24/7Emergency