Taking out a database file (MDF or EDB) from a crashed array is standard recovery. But when you get the file into the engine, that’s not going to be easy: the internal consistency structures have to agree, and a file from a damaged volume will often fail those checks even with almost all of your bytes present. This work fills that gap.
Even if there is nothing wrong with each individual byte of a file, you could still have problems attaching it if it was taken in the middle of a transaction or if some pages were damaged in the wrong places. Getting the file back and getting a mountable database back are not the same thing; you want the second outcome.
Databases go down from both inside and outside, and the two need different work.
This is why you’ll pay more for database recovery compared to simply recovering files.
Recovery of an MDF, IBD or EDB file from a failed disk drive array is routine; getting it in useable format isn’t. To be able to get the database running again, the engine needs to see that each page has been checked by means of checksums, and the allocation maps match the indexes and the transactions are recorded in sequential order in the log. Often, even if just about every byte exists within a file built from a failed disk, this check will fail.
The next step is still yet to come after extraction. Pages will have been validated with damaged pages being identified and mapped back to the table and row they belonged to. In cases of page loss, instead of providing an unusable database when you attempt to attach it, we provide you with information about which objects were impacted by the lost page(s). If the file can’t be brought online at all, we can often extract records directly from the pages and export them as usable data.
Including mail stores that work in ways similar to database systems.
MDF, NDF, and LDF file type databases, suspect databases, as well as page-level corruption across all recent versions of Microsoft SQL Server.
Recovery of corrupt tables from both MyISAM and InnoDB; recovery of InnoDB tables when they were stored on an IBD file but do not have their original tablespace.
Recovery of cluster and tablespace files, including from instances that will not boot.
Recovering EDB storage, transaction logs, and recovering a single mailbox or extracting information from that mailbox if the overall EDB storage cannot be mounted.
There are many small databases associated with other apps (usually the ones no one realised how critical they really were to their business).
File recovery services cost less than our database recovery services as we continue to do work after extracting your data.
The cost of recovering a database starts at £500 +VAT. After a complimentary 48-hour diagnostic we will confirm this price. If physical work is needed on the underlying storage as well then that will be quoted alongside it. A 50% deposit will be required if both types of work need to be done. The balance will be due on successful completion of the work.
Please give us the name of your engine, the version number, how big you think it is (approximate) and what the error message says when you get an error attaching. That can sometimes tell us enough about what might be wrong without needing to see the file(s). NDAs are normal. We can send out invoices.
Just send over your database file(s) with details about the engine version and why they failed to attach for a free diagnostic by one of our engineers. They will look at them, provide a written quote for exactly what you need and then contact you to start working on the project.
Before you post or drop off your device, ask us for a quote via our website or by phone. Your first step towards recovering your information is sending the database files (or if it’s a failed disk drive, send us that) so we can start working on retrieving your lost information. Please let us know which engine you used and what version of that software as well. Once we have completed the free diagnostic, we will confirm the price in writing before beginning any work.
Posting it? We would suggest using a tracked and insured delivery method. Want to drop it off? That’s okay too. Monday to Friday, from 9am to 5:30pm is good; no appointment necessary: simply prepare the item as described above.
Do you want to get a specific quote based on scope first? If so, please provide the details of the database engine used, the file(s), and how bad things are, using the form provided. An engineer will review your request, create a custom quote for you, and respond back to you.
We’ll be in touch shortly. If it’s urgent, call 01865 593000.
Some common types of questions regarding database recoveries.
Usually. Suspect typically means that the engine was unable to recover the database into a consistent state. This can occur after a crash event, or when a recovery operation fails. In either case, the data contained within the files is examined outside of the database engine, where any damaged page(s) are located and identified. At this point, the database may be recovered and returned to working condition, or at least the records may be pulled out of the database.
Often, yes. The data file contains most of the content, and a database can frequently be brought back up (online) without the log file, though transactions in progress at the time of failure may be left in an inconsistent state; we will indicate which table(s)/object(s) were impacted by this issue.
This would generally occur when damage has occurred to one or multiple page(s) within the database file, usually resulting from physical issues such as a “bad” sector or an interrupted write operation. The engine will either refuse to attach or report a consistency error regarding a particular object. We map damaged page(s) to their respective table(s), row(s) and/or other applicable information that they pertain to so you can see directly what was impacted.
Yes, we recover EDB stores and transaction logs, with single mailboxes extracted when the store cannot mount at all. Exchange behaves like a database, and thus is treated similarly.
It’s typical after performing file-level recovery, and this is exactly what database work addresses. Since a byte-for-byte identical file may still result in failing consistency checks, the work will continue past extracting the data to verify pages and correct structural issues until it finally mounts successfully.
From £500 (plus VAT). All prices are agreed to via a fixed price written quotation based on our free 48-hour diagnostic. If there is also a need for physical work on the underlying storage then this will be included in the quotation along with a 50% deposit, with the remainder due upon successful completion of your recovery.
Free diagnostic; tiered pricing starting at £500; in most cases you only pay if we recover your data; every database engine supported including SQL Server, MySQL, Oracle etc., files & storage alike. Start your recovery today!