Skip to content
AS

Database Recovery

Databases can be recovered from their data files, their logs and their backups — and often from a combination. AS works at the page and record level to extract what is consistent and usable.

When you need this

  • SQL Server database in SUSPECT or RECOVERY_PENDING state
  • MDF/LDF or InnoDB files corrupted after disk failure or power loss
  • Tables or records deleted without a usable backup
  • Database files partially encrypted by ransomware
  • Backup files (.bak, .dmp) corrupted or incomplete
  • Storage beneath the database failed

What we do

File-level analysis

Data files are parsed directly, bypassing the database engine, to extract tables, records and objects from damaged pages.

Log and transaction analysis

Transaction logs are examined to recover recent changes and, where possible, deleted records.

Backup recovery

Damaged or partial backup files are analysed for recoverable content.

Partial-encryption cases

Ransomware often encrypts only part of large database files. We assess how much unencrypted content remains and extract it where technically feasible.

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.

What affects the outcome

Outcomes are never guaranteed. Every case is assessed on its own condition, and we tell you what is realistic before you commit.

  • 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 and extract data from damaged SQL Server and MySQL files on your own systems.

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 can discard data that a file-level recovery could have retrieved.

How much of a ransomware-encrypted database can be recovered?

It varies by variant and file size. Some encrypt only the first portion of each file, leaving much of a large database intact; others encrypt fully. We assess before quoting.

Can you recover deleted rows?

Sometimes, from unallocated pages or transaction logs, provided the space hasn't been reused. Time matters.

Request assessmentEmergency