Databases fail loudly and with specificity, and the error the engine returns rapidly narrows down where the fault is. But then, once the file has been retrieved, comes the part that separates this from ordinary file recovery: recovering the file itself is often the easy half, and having the engine mount and accept it is the difficult half that takes the work. If a recovered MDF or EDB will not attach, it is not a successful recovery, and we do not treat it as one.
Getting a recovered database to mount is what distinguishes this work from ordinary file recoveries, and it's where most of the effort really goes.
Anyone can pull out a damaged disk volume's MDF or its EDB. And the file returns with the correct size, appears fully intact... and yet the engine simply won't attach it; or when it does, tells you that your database is suspect... so you're still back at square one.
Inside databases there exist structures (page headers, allocation maps, transaction logs and the dictionary describing the schema) which all reference one another and require internal consistency. When one of those structures becomes damaged, you can have a file which exists but cannot be opened. True recovery involves repairing this internal structure, so the engine accepts the file, and verifying it is acceptable for opening by “mounting” it here before returning it.
A database job is not considered complete by us until the database has opened.
The engine identified some inconsistency when starting up and did not want to make things worse, so it stopped instead. This can often be resolved by replaying the transaction log (no file repair needed).
The store was shut down in an unclean state, and the logs were not replayed. When the log files remain available, it often resolves through replay as opposed to recovery operations.
InnoDB was unable to reconcile a per-table file with the InnoDB dictionary that describes it. The orphaned .ibd files can be recovered; however, they require the schema to be rebuilt around them.
The file exists and the engine refuses to use it. It is due to header corruption, corruption on pages or a mismatched log. This is also the class where extraction alone does nothing.
The fenland food industry relies on traceability. Traceability includes batch numbers, origin/provenance information and cold-chain tracking. These records are stored in SQL and in a surprising number of ageing bespoke systems. If a grower/packer cannot provide the required records for auditing, they lose their contract and not just the data. These jobs come with a predetermined outside date/time limit and no possible extensions.
The second flow is professional: case management and land record information from practices based in Bury St Edmunds, Chelmsford and Cambridge, which is frequently subject to disclosure requirements making the recovery both an evidential process and a technical process. The third is research: experimental/instrument databases from the university and the science parks, often in formats the original software can no longer access even when the file has returned.
Stop the service before copying anything. You cannot produce a reliable copy of a live database while the engine is still running; a copy made that way will not attach. Shut down the service and then copy, or simply give us the volume to use.
Recovery of databases begins at £500 +VAT. When the database sits on a failed array, we quote both the reconstruction of the array and the repair of the database together as one price; they're not billed as separate work orders.
We do verify, and it's included. We won't send back a database until it's been mounted here and confirmed to be able to open. There is no value in paying for a file that cannot be attached.
Rarely. “Suspect” means the engine encountered an inconsistency and stopped instead of risking further complications. If the transaction log survives, then a great deal of what was lost will usually be recoverable. Do not use Repair (Allow Data Loss) as your initial fix.
Typically, the issue is a dirty shutdown rather than damage to the database. Often, if all the log files exist, you should be able to get the store into a clean state by allowing it to replay those logs. Save every log file: deleting them to gain some free space is what converts this into a “real” recovery project.
Yes, and that is most commonly how it goes. First the array is reconstructed, then the database files are extracted; then they are repaired until they mount. This is quoted as one job rather than two jobs.
Recoverable, but the schema has to be recreated in order to work with them. InnoDB stores table structure separately from data. Send anything else that survived: a dump, a backup, an old copy of the schema all shorten the time required for the job.
A seasonal pattern here. Sage files have fixed structures and recover predictably once the underlying volume is accessible again. At the first call, tell us the deadline and we will say honestly whether it is achievable or not.
Yes. It is mounted in this location and confirmed to open before returning any data. Verifying it opens prior to returning any data is the key difference as to whether you have a file or a recovery, and is incorporated into the process rather than being an extra.
Quoted after running diagnostics, with a 50% deposit and the remaining amount due upon successful completion. Databases that copy cleanly may still fail to attach; thus we check for structural integrity page by page (instead of simply handing them back based on a file size).