Database corruption usually violates the "rules" of this type of trade; in many cases, the hard disk itself is perfectly fine and it is within the corrupted data (the SQL Server database has been marked as suspect, an Exchange store was unmounted but will not mount again, MySQL tables which crash the engine when contacted) that damage exists. The recoveries are successful or unsuccessful based upon one discipline: all repairs occur on a copy since the built-in tools that claim to be able to correct the corrupted file(s) are also licensed to remove them.
Database applications are finicky tenants. If you kill the power in the middle of a transaction, their pages will be torn; if a single sector on your hard drive becomes corrupted (even a small amount) it can render entire indexes and/or tables unreachable; or, if you run out of disk space while replaying your logs then Exchange will declare that the store has been "dirty" and shut down. While there may occasionally be physical failures happening with the underlying storage device, in which case the device would first need to be properly documented (i.e., imaged) much like a patient, there are many cases where the problem is purely structural.
In either case, we are all working from the same stuff: an accurate duplicate of the MDF and LDF (SQL), EDB and its logs (Exchange), or InnoDB and MyISAM (MySQL), prior to any tool that has "repair" as part of its buttons accessing these files.
Microsoft named it honestly and people run it anyway. SQL Server's "last resort" repair process essentially does just what it says. It will ensure the database is consistent through deletion (pages, rows, whole tables) of anything it cannot reconcile, and this will be done permanently in the primary/original instance. The "hard repair" process for Exchange ("eseutil /p") also follows a similar model. If you run either of these processes on the only available instance, they will take a recoverable corruption and create a permanent missing item.
We have created our own version of the same process but we are doing it against a duplicate/clone of the original data set, one record/page at a time. We are able to save many records from being lost due to the blunt methods used to perform the previous operations. When a table has been damaged beyond salvation, you will know how badly it is damaged, with the original still intact.
What you receive after performing one of our recovery processes is not simply a collection of folders/files; instead, you receive a fully functional database that can be mounted. SQL Server data will be restored to a point where the database is in a consistent state that can be attached. As part of the restoration process, you will receive documentation of which tables were recovered successfully and which failed. Exchange stores are restored to a clean shutdown state, or individual mailboxes are extracted when the store containing those mailboxes is no longer viable. MySQL and other smaller engine applications (Access, SQLite, line-of-business formats) are rebuilt to a point where your application can open/access them. Where data was lost, you get a precise account of it.
As all jobs have different shapes and sizes, the quote for each job is made separately and written down as soon as the free assessment has been completed prior to any paid work commencing. Each job starts with a free diagnostic, and finishes exactly how it was initially quoted. On most jobs, we do not charge for anything unless we recover your data. We never use an hourly rate, and we do not surprise you with an evaluation fee or take a percentage of the value of your recovered files.
Before diagnosing your SQL Server problem, take the database offline and create a copy of the MDF and LDF files to a secure location (this is step one). Do not constantly disconnect and reconnect the database, nor should you run the repair command against the original database. Once you have created a clean version of your database in a secure location, the assessment is free and the repair process is performed without creating further errors.
This increases the risk, but does not change what is possible. Page level recoveries generally can recover almost all of the rows in a severely damaged database. In addition, because the recoveries are made directly from the damaged file(s) there is little chance for shortcuts if a backup is unavailable. The free assessment will give you the percent recovery estimate before you commit to doing the repairs.
Yes, in nearly every case. An unclean shutdown will leave the EDB waiting to recover from a log replay that cannot be completed. We can recover the database to a clean state by working from copies of the database. Or if the database container is too damaged, we may have to lift each mailbox out individually. Do not use eseutil /p on the original: that is about the only thing you could do to close all other paths.
Yes, that's two of our jobs stacked: first we image the drive as a hardware patient, then we fix database files from the image. It is common on servers, where the disk fault caused the pages to be torn apart. One evaluation will cover both layers.
Before posting or dropping off your item please obtain a quote using either the form on this site or by calling us. There are then two genuine options. No vans will be used. To hand over your item, go to Tay House, 300 Bath Street (only two minutes from the M8) at Charing Cross, Monday to Friday, 9am–5:30pm. We do not require appointments. Or wrap your item securely and send it to us by insured, tracked post from Paisley, Ayrshire, the Highlands or anywhere else in the UK. Either way, the work is done in-house by our own engineers, with a documented chain of custody, and your data never leaves the UK.
Take a copy of each database file before attempting to make any repairs. Stop all other attempts to fix. The no-cost assessment will then show you how much can be recovered and we will quote you the price (from £500 + VAT), which will be confirmed in writing beforehand. We are experienced with database recovery for Glasgow companies, including SQL Server, Exchange, MySQL etc., and our engineers work with the database at page level to rebuild where possible and mount back up.