Every Engine. One Service.

Database Repair Services

Free 24hr Diagnosis No Recovery, No Fee Read Only Originals NDA Available

A database that will not open is not the same as a database that is gone. Our repair service reads damaged files at the binary level, across SQL Server, MySQL, PostgreSQL, Access, SQLite and more. You get a free diagnosis first, a fixed quote second and your data back third. The original file is never touched.

Start a Free Diagnosis

See Pricing

Damaged Database? We Repair Every Type and Application

One place takes the damaged file, whatever wrote it, then hands back the data.

Any type of database

SQL Server, MySQL, PostgreSQL, Access, SQLite, DBF, Firebird and the rest. One service covers all 8 engine families and 25+ file types.

Any cause

Power loss, failing disks, interrupted copies and ransomware damage every engine the same way. The repair method starts from the file, so the cause never limits it.

Written here since 2013

The repair engine is our own work and ships inside our desktop tools. You deal with the people who wrote the code.

Coverage

Database Engines We Repair

SQL Server

Our deepest specialty. Binary level repair of data files, secondaries, backups and logs from SQL Server 2000 to 2025.

.mdf.ndf.bak.ldf

MySQL & MariaDB

InnoDB tablespaces and legacy MyISAM tables, including crashed servers where only the data directory survives.

ibdata1.ibd.frm.myd

PostgreSQL

Data directories that refuse to start, damaged base files and clusters left behind by failed upgrades.

base/pg_walpg_control

Microsoft Access

Unrecognized format errors, broken forms and files that Compact and Repair gives up on.

.accdb.mdb

SQLite

Malformed disk images from apps, phones and embedded systems, including orphaned WAL and journal files.

.db.sqlite-wal

dBase & FoxPro

Legacy DBF tables with damaged headers, broken memo files and index wreckage from decades-old systems.

.dbf.fpt.cdx

Firebird & InterBase

Corrupt FDB and GDB files behind point of sale and vertical market applications.

.fdb.gdb

Oracle & Others

Enterprise engagements for Oracle datafiles plus legacy formats such as Paradox, DB2 and Informix. The free diagnosis tells you if we can help.

.dbfcustom

Applications

The Applications Behind the Files

Many business applications are a database wearing a user interface. When the application will not start, the database underneath is usually the patient.

ACT! CRM

ADF contact databases, which are SQL Server files under another name. Contacts, history and notes come back.

SharePoint

Content databases holding document libraries and lists. The documents inside the MDF are recoverable files.

Dynamics GP & Sage

Accounting databases where every row is a transaction. Ledgers and journals are extracted table by table.

WSUS & WID

Windows Internal Database instances that server roles depend on, repaired from the raw files.

BizTalk & SCCM

Infrastructure databases where a rebuild from scratch costs weeks. Repair recovers the configuration state.

Point of Sale Systems

Retail and restaurant systems built on Firebird, SQLite or DBF, where the sales history is the business.

Mobile & Embedded Apps

SQLite stores from phones, kiosks and devices, often the only copy of the data that ever existed.

Custom Line of Business Apps

In-house software whose developer is long gone. We work from the file, no source code needed.

Damage Patterns

Corrupt Database Problems We See Every Week

The causes repeat: power failure mid-write, a disk going bad underneath the file, interrupted copies, failed updates and checksum errors such as 823 and 824. The effects repeat too.

Suspect and Recovery Pending

SQL Server marks the database unusable after finding damage. The data is still in the file, the server just refuses to serve it.

Torn Pages After Power Loss

A write that stopped halfway leaves pages that fail their checks. Everything around them is usually intact.

Deleted Rows and Dropped Tables

Deletion marks space as free. It does not erase it, so until the space is reused the rows are still physically there.

Truncated and Partial Copies

A copy over the network that was cut short, leaving a file that ends mid-page. What was copied is recoverable.

Backups That Will Not Restore

The backup exists but RESTORE rejects it. The data inside the backup is read directly instead.

Header and Boot Page Damage

The first pages are gone while the rest of the file is fine. Structure is rebuilt from what survives.

First Aid

Before You Do Anything Else

Most databases that arrive unrecoverable were damaged after the original failure, not by it. Four rules protect what is still there.

1. Stop writing to it

Every new write can reuse the pages that hold your deleted or damaged data. Take the application offline.

2. Copy the file now

Make a plain file copy before anyone experiments. All repair attempts should run against copies.

3. Skip the destructive repair

REPAIR_ALLOW_DATA_LOSS and similar options delete what they cannot validate. Diagnose first, decide later.

4. Do not retry endlessly

Repeated attach and restore attempts on failing hardware make bad sectors worse. Two failures are enough evidence.

From Intake Experience

The Second Corruption: How Rescue Attempts Finish the Job

A pattern we see weekly at intake: files that arrive with two layers of damage. The failure that started it and the rescue that finished it. Every case below is avoidable in the first hour.

chkdsk truncates what it cannot fix

Filesystem repair fixes cross-linked clusters by truncating them. The volume comes back healthy and the database file comes back shorter.

Prevention: copy the file off the volume before any disk repair runs.

The destructive repair option

REPAIR_ALLOW_DATA_LOSS on the only copy deallocates pages it cannot validate. The next write reuses them and recoverable damage becomes permanent loss.

Prevention: destructive repairs run on copies or not at all.

Antivirus mid-write

An AV engine flags the database during heavy writes and yanks it out from under the engine. The corruption is real and the cause is invisible in the SQL logs.

Prevention: exclude database files and folders from real time scanning.

The snapshot mismatch

A VM snapshot revert that catches the data disk but not the log disk produces an MDF and LDF from two different moments. Each file is healthy. The pair will not attach.

Prevention: snapshot and revert all database volumes as one unit.

The wrong copy method

A standard copy aborts at the first unreadable sector. On a dying disk, what you copy with decides what survives: error tolerant imaging captures everything around the bad spots.

Prevention: on failing media, image first and copy from the image.

The pattern behind them all

Most databases that arrive truly unrecoverable were killed by the second event rather than the first. The original corruption was survivable.

Prevention: after a failure, change nothing until the file is copied.

Honest Triage

When You Should Not Repair the Database

Repair is one route out of a bad day. Sometimes it is the wrong one. Four questions settle it before any money moves.

1. How old is the last clean backup?

If last night's backup restores clean, replaying one day of lost work is usually faster and more complete than any repair. Repair wins only when the backup gap costs more than the corruption did.

2. Does a replica already hold the data?

Log shipping, mirroring and availability groups all keep copies. A healthy secondary is a cleaner source than any repaired primary. Check the topology before shipping anything anywhere.

3. Can the data be regenerated?

A corrupt WSUS or SCCM cache database should be rebuilt, not repaired. Repair is for data that cannot be recreated from another source, not for infrastructure state that rebuilds itself.

4. Is 97 percent actually enough?

For financial books, a partial ledger can create more audit exposure than a documented total loss. When completeness is legally material, decide with your auditor before deciding with us.

The working question behind all four: what would it cost to recreate this data from other sources? If that number is smaller than the quote, do not approve the quote. We will tell you the same thing on the phone.

The Process

How the Database Repair Service Works

You always know what is recoverable and what it costs before you spend anything.

Send the File

Contact us and receive secure transfer instructions. Large files travel by encrypted transfer or by courier on encrypted media.

Free Diagnosis Within 24 Hours

We read the file and return a report listing the tables, row counts and schema objects that are readable. No charge and no obligation.

Fixed Quote, Your Decision

The quote is based on the diagnosis and it does not change after you approve it. If the report shows nothing worth recovering, you owe nothing.

Repair and Verified Delivery

You receive the repaired database in your chosen format with a verification report of recovered tables, rows and objects. Your original file is never modified.

Methodology

Inside the Free Diagnosis: What We Read in the First Hour

The file's own structures predict the outcome before repair begins, which is why a fixed quote is even possible. Here is the actual sequence, written by the people who wrote the parser.

Header and boot page

The file header and the database boot page carry the version, the state and whether the structural spine exists. Five minutes of reading that predicts half the outcome.

Allocation maps, read before the data

Allocation pages tell us which regions of the file should hold data before we read them. We know what ought to exist, then check what actually does.

Damage topology

Scattered single page checksum failures point at memory or controller corruption. Long contiguous runs of dead pages point at disk surface damage. The pattern names the culprit and predicts whether more failures are coming.

System catalog reachability

If the tables that describe the tables survive, recovery is reconstruction. If they are gone, it is carving. Different method, different confidence, different quote.

The loss list

The report states what is not recoverable with the same precision as what is. That number is what a business decision actually needs and it is why the quote after diagnosis never changes.

Honest Advice

Try Our Tools First

The same engine that powers this service ships inside our Windows desktop tools. If the tool fixes your file for a license fee, you never need the service. The service exists for the rest: rare engines, multi-file wreckage and cases that need human hands.

SQL Database Recovery

Repair corrupt and suspect MDF files yourself, on your own machine.

Open Tool

MDF Repair

Focused repair for a single damaged SQL Server data file.

Open Tool

SQL Backup Recovery

Recover data from a .bak that will not restore, without RESTORE.

Open Tool

Free MDF Viewer

Look inside the file free before deciding anything at all.

Open Tool

Tool, Service or Lab: The Short Version

	Univik Desktop Tool	This Repair Service	Physical Recovery Lab
Best when	The file is readable and it is a SQL Server format the tools cover	The engine is rare, the wreckage spans files or you want experts to handle it	The drive itself is failing and the file cannot even be copied
What you need	A Windows PC and the damaged file	The file or an image of it, sent over encrypted transfer	The physical drive, shipped to the lab
Cost shape	One-time license fee, free trial first	Free diagnosis, then a fixed quote from $299 per database	Quoted by the lab after inspection
Who does the work	You do, on your own machine	Our engineers, with a verification report back	Lab technicians in a hardware facility
Start here if	You want to try the cheapest route first	The tools were not enough or the engine is not SQL Server	The disk clicks, disappears or throws hardware errors

The three routes chain together: a lab images the drive, the tools take a first pass and the service catches whatever is left.

Confidentiality

Your Data Is Handled Like Evidence

Univik has built digital forensic software since 2013. The same handling discipline applies to every service case.

Read Only Originals

Your file is imaged once and worked on as a copy, the way ISO/IEC 27037 expects digital evidence to be preserved. The original is never written to.

Encrypted Transfer

Uploads are encrypted in transit and files rest on isolated machines while the work runs.

NDA on Request

A signed confidentiality agreement is available before you send anything.

Hash Verified Integrity

The source file is hashed with SHA-256 on arrival and checked again at delivery, proving the original never changed in our hands.

Forensic Method

Handling follows the forensic practices in NIST SP 800-86: work on copies, preserve the source and document every step.

Wiped After Delivery

Once you confirm the delivery, every copy of your data on our side is erased following the NIST SP 800-88 media sanitization guidelines.

Privacy Laws Around the World

A repaired database often contains personal data. Our handling supports your obligations under the laws that govern it.

What applies and how we support it

GDPR and UK GDPR: we act on your documented instruction only, a data processing agreement is available and your data is deleted after delivery following NIST SP 800-88.
HIPAA: when the database holds health records we sign a Business Associate Agreement before the file is sent.
CCPA and US state privacy laws: we handle the file as a service provider, use it for the repair alone and never sell or share it.
GLBA: financial customer data is safeguarded with the encryption, isolation and sanitization practices described above.
DPDP Act, PIPEDA and Australian APPs: the same processor-style handling covers data governed by Indian, Canadian and Australian law.

What does not apply, said plainly

PCI DSS: only relevant if the database holds cardholder data. Most repair cases do not and the diagnosis will tell you if yours does.
SOX: we recover your financial records but we are not your auditor. Integrity reporting from the repair can support an audit, it does not replace one.
FISMA and FedRAMP: these govern US federal systems and authorized cloud providers. We hold no FedRAMP authorization, so federal agency data should go through an authorized channel.
Legal determination: which law governs your data is a question for your counsel. We tell you exactly how the file is handled so that call is easy to make.

Corrections

Database Repair Myths, Corrected

Half of what people believe about corruption is wrong in both directions. Less is lost than feared and less is guaranteed than advertised.

The myth	The reality
Corrupt means the data is gone	Corruption damages pages, not files. A 100 GB database with 50 damaged pages is 99.99 percent intact and behaves as if it were dead.
A failed RESTORE means the backup is dead	RESTORE is strict by design. The data inside a rejected .bak file is usually readable directly, without RESTORE ever succeeding.
REPAIR_ALLOW_DATA_LOSS repairs the database	It deletes whatever it cannot validate and the deleted pages are gone for good. Diagnose first, on a copy.
Cloud and managed databases cannot corrupt	The platform protects the storage layer, not your logic. Deletion, ransomware in the application tier and damaged exported copies all still happen. The SQLite inside your product ships with no platform at all.
Bigger files have worse odds	Recoverability tracks where the damage sits, not how big the file is. A small file with a shredded system catalog is a harder case than a huge one with damaged user pages.

Pricing

Database Repair Pricing

Free Diagnosis

Every case starts here

Readable-object report within 24 hours
Tables, row counts and schema objects listed
No charge and no obligation
No recovery means no fee, ever

Start Free

Standard Repair

From $299

Per database, fixed quote

Quote fixed before work starts
Typical delivery in 2 to 5 business days
Output as database file, SQL scripts or CSV
Verification report included

Get a Quote

Enterprise & Legal

Custom

Complex and regulated cases

Multi-file and multi-server wreckage
Chain of custody documentation
Priority timelines and reporting

Talk to Us

Feedback

What Clients Say

Our ERP database went suspect on a Friday and the last backup was three weeks old. The diagnosis came back Saturday morning listing every table as readable. We approved the quote and had the data on Tuesday.

IT Manager, manufacturing firm

The point of sale vendor went out of business years ago and the Firebird file behind it corrupted. Nobody else would touch it. Univik pulled six years of sales history out of that file.

Owner, retail chain

We needed the recovery documented for a legal matter. The report listed exactly what was recovered and how, with the original preserved untouched. It held up.

Litigation support consultant

From the Bench

Recent Case Notes

Three anonymized cases that show what the work actually looks like.

Suspect MDF, 38 GB, manufacturing ERP

Torn pages after a power cut left the database in Recovery Pending and DBCC could not complete. The diagnosis found 61 of 63 tables fully readable. Repair carved the two damaged tables page by page and delivered 99.2 percent of their rows, with the loss list documented row by row in the verification report.

ibdata1 only, crashed MySQL host

A failed disk took the server and the backups were on the same volume. The client had one file: ibdata1 copied from a partial image. Table definitions were rebuilt from the data dictionary inside the tablespace and 214 of 216 tables were recovered into a fresh MySQL instance.

Firebird POS, six years of sales

The vendor was gone and the FDB failed validation after an update loop. Record versions were walked directly from the page structures. Sales, inventory and customer tables came back complete and were delivered as both a working FDB and CSV exports.

Advanced

When the Repaired Database Must Survive Cross-Examination

Litigation and audit work sits where data recovery meets digital forensics. In contested matters, how the data was recovered matters as much as what was recovered. This is what changes when a repair becomes evidence.

Work the image, never the artifact

Acquisition hash, then a forensic image, then all repair on copies. The original you may later be compelled to produce stays provably untouched from the moment it arrived.

The loss list as a legal document

Opposing counsel attacks completeness. A verification report that enumerates the unrecovered ranges answers the question before it is asked.

Deleted rows cut both ways

Ghost records recovered for your side are ghost records the other side can demand. Scope the deleted-data carve deliberately and in writing before it runs.

Reproducibility is the defense

An expert challenge asks whether a second run would produce the same output. Deterministic tooling with documented parameters is the answer. Ad hoc hex editing is not.

Before any bytes move, counsel can tick five boxes:

Protective order and confidentiality terms mapped to the engagement
DPA or BAA signed where regulated data is present
Chain of custody format agreed with both the lab and the court
Scope of deleted-data recovery fixed in writing
Original artifact return or certified destruction decided up front

Questions

Database Repair Questions

SQL Server files are our deepest specialty, covering MDF, NDF, BAK and LDF at the binary level. We also repair MySQL and MariaDB tablespaces, PostgreSQL data directories, Access ACCDB and MDB, SQLite databases, dBase and FoxPro DBF, Firebird and InterBase files and application databases such as ACT ADF. If your engine is not listed, send the file anyway and the free diagnosis will tell you what is readable.

The diagnosis is free and produces a report of what can be recovered. After that you receive a fixed quote based on the engine, the file size and the damage, typically starting at $299 per database. You approve the quote before any paid work starts and the price never changes after approval.

The free diagnosis is usually returned within 24 hours. Most standard repairs complete in 2 to 5 business days. Very large files, striped backup sets and multi-file wreckage can take longer and the quote states the timeline up front.

Yes. Transfers are encrypted, the work happens on isolated machines, an NDA is available on request and every copy of your data is wiped after you confirm delivery. Univik has built forensic software since 2013 and the same evidence handling discipline applies to service work.

No honest service can. What we guarantee instead is transparency: the free diagnosis lists the tables and objects that are readable before you pay anything, so you know exactly what you are buying. If the diagnosis shows nothing worth recovering, you owe nothing.

No. The repair works on the raw files. You send the damaged file itself and receive repaired output you can load anywhere: a rebuilt database file, SQL scripts, CSV exports or a combination that fits your target.

Large files are normal in this work. Multi-gigabyte databases travel by secure transfer or encrypted disk by courier for the largest cases. Size affects the timeline more than the feasibility.

A repaired database in the format you choose plus a verification report listing recovered tables, row counts and schema objects such as views, stored procedures, functions and triggers. Your original file is never modified, everything is written to new output.

Often yes. Deleted rows leave ghost records inside the file until the space is reused and dropped tables leave their pages behind. The diagnosis states whether that residue is still present in your file before you commit to anything.

Contact us with the engine name, the file type and a short description of what happened. We reply with secure transfer instructions, run the free diagnosis and send the report with a fixed quote. From there the decision is yours.

Be very careful. DBCC CHECKDB is the right diagnostic and running it without a repair option is safe. REPAIR_ALLOW_DATA_LOSS is a different matter: it deletes whatever it cannot validate, which can silently destroy recoverable pages. Never run it on your only copy of the file. Take a copy first, run the free diagnosis on the original and you keep every option open.

Then the drive comes first. When a disk is clicking, unreadable or throwing hardware errors, no software repair can help until the media is imaged, because the file cannot even be read. Have a physical data recovery lab image the drive, then send us the imaged database file. We repair from files and images, which is exactly what a competent lab hands back.

Yes. Media holding your data is erased following the NIST SP 800-88 media sanitization guidelines. File handling follows the forensic practices described in NIST SP 800-86 and ISO/IEC 27037: the source is hashed with SHA-256, imaged once, worked on as a copy and preserved unchanged. A chain of custody record is available for every case. For regulated data we sign a GDPR data processing agreement or a HIPAA Business Associate Agreement before you send the file.

Usually yes. Corruption almost never destroys a whole file, it damages parts of it. A repair reads around the damaged pages and rebuilds the database from everything that survived, which is most of the file in the majority of cases. The free diagnosis tells you exactly how much of yours is readable before you spend anything.

A database repair service takes a damaged database file that will not open, reads it at the binary level and returns the recovered data in a usable form. Unlike do it yourself tools, a service handles the work for you, covers many engines and includes verification reporting. Ours starts with a free diagnosis and a fixed quote.

The Diagnosis Is Free. Start There.

Send the damaged file and know within 24 hours exactly what is recoverable, before you spend anything.

Start a Free Diagnosis

Other Univik Services

Email Migration Services

Move mailboxes between servers, clouds and clients with the data intact.

Learn More

Data Recovery Tools

The full catalog of Univik desktop tools for files, email and databases.

Browse Tools