SQL Server Data Recovery

Behind your business is at least one database. This database might keep records of your clients and your sales. It might keep track of patient records. It might be a part of your POS system. Whatever it does, by far the most common way to manage and access your database is through a SQL database management system such as Oracle, MySQL, or Microsoft SQL Server. With so much important work resting on it, it’s bound to hurt if your finely tuned SQL Server crashes hard, or if data corruption locks you out of your database and you get a SQL server error.

Repairing and Salvaging Corrupt SQL Databases

Your SQL database is a relational database. One thing a relational database must provide, above all else, is data consistency. If a sector goes bad or a bit flips somewhere in your SQL database, the results could be catastrophic. A doctor could end up prescribing 3,000 milligrams of a medication to their patient instead of 300. Or a business’s payroll department could end up paying someone $10,000 instead of $1,000. If Page 9 of your database, also known as the “boot page”, goes bad, your entire database could just become a proverbial brick. SQL is very conscious about these kinds of data corruption. So in some cases of data corruption, SQL can block your access to the entire database for your own protection. If you use Oracle to manage your SQL database, you may see Oracle error code ORA-600 [633]. If you use Microsoft SQL Server, you may see the SQL error code 8909.

It may be done for your protection—and sometimes, if a critical part of your database’s architecture like the boot page becomes corrupted, it may be impossible to avoid—but it certainly seems unfair to lock you out of your entire database because 1% of it became corrupted. 99% of that data is still good, and you need it! Luckily for you, our data recovery technicians here at Gillware are experts at dealing with SQL database corruption. There’s no need to let SQL throw out your baby with the bathwater. We can repair your corrupted SQL database and salvage all the healthy data you need from it.

SQL Server Data Recovery Services

In simplest terms, your SQL database, at its core, has two components. There is the SQL MDF database file itself, which (of course) has your database in it. Then there is the log file. This file records all of the changes made to the database. The log file doesn’t make your database immune to corruption, but it does make it fairly resilient against accidental corruption. Whenever you alter the data in your SQL database, the changes are recorded in the log file before they are actually made. If something happens—like, say, a power outage—the database will see that a write operation was not completed and use the log to “roll back” to just before the change was made. This helps prevent accidental data corruption. But unfortunately, it doesn’t help much when the hard drives themselves in your server fail.

The servers we see at Gillware tend to have some degree of fault tolerance in their RAID arrays. For example, RAID-5, a very popular setup, can withstand one drive failure. RAID-10 and RAID-50 can withstand one or more failures. And RAID-6 can withstand two drive failures. But unfortunately, just because RAID arrays are fault-tolerant doesn’t mean they can’t fail.

When our engineers receive crashed servers, it’s not uncommon for them to have failed during the rebuild process. As hard drive capacities grow, the amount of time it takes to integrate a new drive into a server rise accordingly. This also puts extra strain on the remaining drives. Therefore, RAID arrays are becoming increasingly vulnerable to drive failure while they are being rebuilt. It is sadly common as well for us to see RAID-5 servers in which one drive failed and the user, knowing the risks of rebuilds, put off rebuilding it until a second drive failed. But by then, it was too late.

Repairing the RAID Architecture to Recover Your SQL Server

When we receive your SQL server for data recovery, we bring your hard drives right to our cleanroom for analysis. Our data recovery experts will assess the damage to the failed disks. In our cleanroom, we can determine what kind of work will have to go into salvaging your data. Once we have a clear picture of your server’s state of the union, we send you a price quote and probability of success. After you approve the quote, we go on ahead with the rest of our SQL server data recovery efforts.

After we make the necessary repairs to the drives in your SQL database server, we create disk images of all of them for forensic analysis. These images, created on our own healthy hard drives, then go to our RAID data recovery technicians. We piece your server RAID array together and poke around at all the data on it. If damage to your server’s drives prevented us from creating a perfect 100% disk image of each drive, there could be holes and gaps in important parts of your database. Our engineers have to check for any data loss or irreparable corruption in your SQL database.

Once we’ve gotten everything we can, we show you the results. If anything is missing, we let you know. We always strive for a 100% recovery of your database, but it isn’t always possible in every circumstance. Ultimately, in these edge cases where your SQL database isn’t perfectly recovered, it’s up to you to determine whether our SQL server data recovery efforts have yielded your most critical data.

For more information on SQL data recovery, please read the case studies below: