Databases fail with great fanfare; they tell you exactly what has failed, and therefore allow you to isolate the cause quickly. What follows is where database recovery becomes distinct from simple file recovery: while recovering a file is relatively easy, getting the engine to accept the file after recovery is the hard work.
You can have a byte-for-byte exact copy of your database data file and it can still refuse to attach if it was captured mid-transaction or has damaged pages in the wrong place. Until you can attach it as a usable database file, all you'll be doing is wasting your time. There is an important difference between recovering your file and being able to recover your database. Only one of those will help you.
When databases go down they scream and tell you exactly where the problem is, so you know right away where to start looking. At first glance that hardly sounds like good news, but it is more helpful than it feels at the time.
It's common practice to pull the file off failed media first. It's not common practice to make the engine accept the file.
An engine expects internal consistency: page checksums match, allocation maps agree with what is allocated, index structures point at real rows, log sequence numbers are in order. A file assembled from a damaged volume frequently fails those checks even though almost every byte is present—and that’s the gap this work closes.
Pages are validated, damaged pages identified and mapped back to the tables and records they belong to, and structures repaired until the database mounts. If a page can’t be recovered, you’ll know which objects were affected rather than being given a store that won’t attach. If the file can’t be brought online at all, records usually can be extracted directly from the pages and exported as usable data—not elegant but better than nothing.
All databases including small ones that turn out to be business-critical.
Microsoft SQL Server — MDF, NDF and LDF files; suspect databases; page-level corruption across all recent versions. MySQL and MariaDB — InnoDB and MyISAM including IBD files without their original tablespace. PostgreSQL and Oracle — cluster and tablespace files; instances that will no longer start.
Microsoft Exchange — EDB stores and transaction logs, with individual mailboxes extracted if the store will not open at all. Access, SQLite and embedded databases — in line-of-business apps, these were usually the ones nobody knew the company was dependent upon until they could no longer be opened.
Priced above file recovery because database recovery continues after extracting data.
The cost for database recovery begins at £500 + VAT, which will be confirmed as soon as we complete our free 48-hour diagnostic. If your storage requires physical work, we will quote that alongside it and take a 50% deposit, with the remaining balance due on success.
We require you to provide us with some information about the engine and version of the database, its size (approx.), and the actual words used by the error when attempting to mount — this may well help identify the class of fault before your files arrive. We accept NDAs & offer invoice options.
Send us the database files and provide information on your engine type, engine version and what occurred. The diagnostic that follows costs you nothing, and we give you a firm written quote for work prior to commencing.
We don't start working on your data recovery case until the database files — or the failed storage holding them — reach our bench. Please package it carefully so as to prevent damage during shipping. If you'd like us to get started please include all of your contact information with it. We'll need to know which database engine you're running and which version. Once you've done that there's no charge for the diagnostics that follow. One estimate will be provided to you in writing prior to beginning any actual data recovery work.
Posting it? Use a tracked and insured service. The value of what is on the drive far exceeds the cost of postage. Bringing it in? Weekdays from 9am to 5:30pm, and it still needs packing as described above for the journey.
Still unsure whether sending in your data recovery case is worthwhile? Let us know about the type of database engine you're using, the database files and the fault, and any attempts made towards recovering your lost data — each of these will be read by an engineer who will provide you with an objective assessment of the chances for successful data recovery from the failed media you are sending, plus a rough cost range, before you even ship anything.
We’ll be in touch shortly. If it’s urgent, call 0161 871 0788.
These are some of the questions we answer regarding recovering a database.
Typically. "Suspect" means that the engine was unable to place the database into a consistent state, typically after an engine crash or when the engine's automatic recovery failed. We examine the files outside the engine to determine if there were any damaged pages, then repair the database or extract the records from the database directly.
Yes, often. The majority of the contents for a database are held within the data file. Therefore, the database can frequently be made available on-line using the data file alone — although any transactions in progress at the time of failure will have been partially completed, and we will determine which objects were impacted.
Page level corruption refers to damage to one or more individual database file pages. This type of damage is often caused by bad sectors or an interrupted write operation. In this scenario, the engine will refuse to attach the database and/or report consistency errors for certain objects. Once identified, the damaged page(s) are then matched against their original table(s), row(s) etc.
Yes, we can help. A dirty shutdown where the Exchange logs and the Exchange databases do not agree is very common and normally recovered, using individual mailbox extraction if the store can't be mounted at all. Avoid running repair commands first — they can make it permanent.
You have successfully recovered the file; however, it is unable to attach — that is common, and it is exactly what database work addresses. It is possible as part of file level recovery that we may find that although the file was perfectly restored byte-for-byte, it fails some consistency check when attempting to mount. The database work process continues past extraction until it eventually attaches the store.
Database recovery costs start from £500 + VAT and are based on a fixed price agreement provided in writing after our free 48-hour diagnostic. If physical intervention is required on the underlying storage system, this would form part of the quote along with a 50% deposit payable prior to commencement and the remainder paid upon successful completion.
A byte-for-byte image of a database is not a recovered database. A database that was in the middle of a transaction when it crashed can be attached and will immediately crash again. Each page of each database is reviewed for structural integrity before returning any database.
Quoted after the diagnostic, with a 50% deposit and the rest of the money when successful. Even if your database copies cleanly, the engine could still refuse to attach it; therefore these are checked for structural integrity one page at a time as opposed to returning them based on file size.