RAID 5 Data Recovery
RAID 5 is one of the most common RAID setups for small businesses and other organizations. Whatever you use it for, a RAID 5 crash can be devastating for your business. Luckily, there’s somewhere for you to go when the worst happens. Gillware is here to help with our world-class RAID 5 data recovery service. Simply get in touch with us to set up a free in-lab evaluation.
RAID 5 offers, for a small reduction in overall storage, one drive worth of redundancy. RAID 5 arrays will need at least 3 drives but will commonly consist of up to 8. The main idea is that if one drive fails, the RAID controller will remove it from the group but there is no immediate impact to the data or the business. In this degraded state you can still boot, access data and write new data. But, if a second drive fails, none of those things will be true, and your entire array will become inaccessible.
The vast majority of our clients have had a few days of technical history battling this crash. They have worked with their SAN/NAS or RAID card manufacturer’s support personnel to no avail. They may have had their IT technician run RAID 5 data recovery software to no avail: Even the best RAID 5 recovery software cannot fix physically broken hard drives.
Even in situations like these, Gillware still has an over-90% success rate, so don’t lose hope. Your RAID 5 data may still be recoverable.
Why Choose Gillware For My RAID 5 Data Recovery?
There are plenty of good reasons to choose Gillware for RAID 5 data recovery. The best reason by far, though, is that we have some of the world’s best RAID 5 recovery experts at our disposal. Our RAID engineering staff all have degrees in computer science and computer engineering, and most have over 10,000 hours of professional data recovery experience logged over the past decade. We’ve seen it all before and you aren’t going to throw anything at us that is beyond our technical abilities. We also offer free evaluations and financially risk-free data recovery attempts. Unless we achieve a positive result at a budget that works for your organization, you won’t pay us anything.
Talk to a RAID 5 Data Recovery Expert Today!
Our client advisors are available by phone during business hours (M – F: 8am – 7pm; Sat: 10am – 3pm).
Send us an email including the type of phone you have and the problem you are experiencing. A client advisor will respond within 25 minutes during business hours (M – F: 8am – 7pm; Sat: 10am – 3pm).
Have a quick question about the data recovery process? Use our chat feature to chat with one of our client advisors (not a robot!) during business hours (M – F: 8am – 7pm; Sat: 10am – 3pm).
How To Recover RAID 5 Disk Failure – The RAID 5 Data Recovery Process
Step One: The Free Evaluation
We always start with a free evaluation of all of the drives in the RAID. Even if you are 99% certain a hot spare didn’t engage or a drive has been stale for years, send all the drives! We typically do not want you to send in any miscellaneous computer equipment like motherboards or RAID controllers. We bypass all those restrictions that a RAID controller will roadblock us with and bake this cake from scratch.
Step Two: Independent Analysis of Individual Drives
Gillware data recovery engineers will access each drive’s health. If a drive is healthy enough, we will make a forensic write-blocked image copy of their contents. We aren’t just making a copy, though: our data recovery software inspects each and every sector of data, and when it sees file system metadata or file contents that it recognizes as boot sectors, MFT entries, or OLE2 headers, we add that information to a large relational database. Throughout this analytical process, we never alter the data on the original hard drives.
RAID recovery engineers assess each drive independently first and then determine if any of them are stale. Because we have a relational database of all the millions of file entries, we can sort those by date to determine the exact moment each drive fell offline.
Step Three: Determine the Physical RAID 5 Volume Geometry
The biggest breakthrough in any RAID 5 data recovery case is when we have a candidate for a physical volume. We use our relational database of binary sniffs to determine the overall geometry of the RAID 5 volume. We need to figure out whether the RAID controller offset the data, what the stripe size was, what the striping pattern was, and what the drive order was.
Sometimes, we get lucky and can construct a physical RAID 5 volume without any individual drive repairs. In other situations, we have to perform individual temporary repairs to individual drives first, then we make our forensic clones and perform the analysis.
Step Four: Find the Logical Units and File Systems
Having achieved an emulated physical RAID 5 volume on at least n-1 of the drives, we now have to find the Logical Units or LUNs. Many RAID arrays will carve their physical volumes into multiple logical volumes. On a NAS RAID 5 device, for example, you’ll want the Linux operating system on a separate LUN than the user data, or you may want to carve one logical unit for your marketing group and another for the engineering department. On the other hand, some users prefer to have one big LUN that comprises the entirety of the physical RAID.
Step Five: Recover Data From Failed RAID 5 Array
After finding the logical units, we proceed with the data recovery effort just like any other data recovery case. We find all the file system geometry and the file meta data for each file system, and then assign their inodes and dirents to them using our data recovery tools. We then test the individual files, paying particular attention to large, highly fragmented files: Those files will span each and every drive’s data stripes, and their integrity ensures that we have not made any errors in reconstructing the array. We then will be sure to test the most recently altered files to ensure we have an optimal physical build without any stale drive in the mix.
The data is then extracted onto a brand new and physically-healthy storage device for shipment back to the client. We retain the data in our secure data recovery facility for a short grace period to ensure that shipment and extraction goes well on the client side. Then, we completely erase all of the client’s data from our facility to ensure their privacy.
How To Rebuild RAID 5 Without Losing Data
Ideally, an IT professional will be notified of the degraded state from monitoring software, like Nagios, or from the RAID controller. The logical state of the union should be good, the unit is degraded but there is full data access and functionality. However, if data is inaccessible or the volume isn’t online, a rebuild will never help. In fact, it will potentially be catastrophic. All a rebuild does is take the logical state of affairs and make it redundant. If the logical state of affairs is bad, that is something we don’t want redundant.
After confirming that everything from the end user’s perspective is great, the IT professional must pull and then replace the failed drive. This positive logical state will then get back to redundancy by a RAID rebuild process. Some RAID controllers will be configured to automatically rebuild when they detect the new healthy drive. Some will require an operator to run proprietary commands on the RAID card, sometimes through a GUI. The RAID controller will read all the information from the current drives, and run an XOR parity calculation, writing the results to the new healthy drive. At the end of this process the array is no longer degraded and you’re back to redundancy–back in position to have another drive go down safely.
Can You Recover RAID 5 Data From One Drive?
With only one drive of a RAID 5, you will not recover any significant amounts of data. This is because most important files are going to be significantly bigger than the stripe size of the array. A four-megabyte picture will be broken up into hundreds of 64-kilobyte pieces, and in a 4 drive RAID 5 array, each drive will contain 25% of those pieces. We need to analyze and copy each drive so we can determine the overall geometry of the array and to determine which drive set is optimal, but we must have all pieces of the puzzle.
If RAID-5 is so great, then why does Gillware see so many of them come into our data recovery lab?
It sounds like a well-maintained RAID 5 array should never crash. But even well-looked-after RAID arrays can need a trip to a data recovery lab – sometimes even data recovery software can’t cut it. Here’re a few of the reasons why:
1. RAID 5 Is Not a Logical Backup
Even with the redundancy provided by RAID 5, there is no second copy of your data anywhere unless you fastidiously back up the data using a data backup service. If a human makes a mistake and deletes a bunch of data, RAID 5 cannot help you. If a malicious human or process infects the contents of a RAID 5 with a ransomware virus, RAID 5 cannot help you. If you fail to make this distinction between RAID and backup you can get burned by all manner of logical problems and end up calling into a professional RAID data recovery lab.
2. Two Drives Fail in a RAID 5
Multiple drive failure is the most common cause for needing a RAID 5 data recovery. We are commonly called on to recover data from a RAID 5 array with 2 failed drives. Sometimes two or more drives will fail simultaneously because of sudden power loss or a power surge. More often one of the drives has failed historically and we regard its data as stale. Depending on how long a drive has been stale it will have limited usefulness in a RAID 5 data recovery effort.
Regardless of how we got here, with only n-2 drives in the volume, the XOR parity cannot be fully calculated and you are left with 50% or less of the RAID 5 volume’s binary.
The volume’s binary content is actually striped across the drives and the stripe size is typically measured in kilobytes. So you don’t have access to 50% of your files, you only have access to 50% of the binary of each file.
Worse, you’ll only have access to 50% of the file definitions. And this is only if you can even get the RAID controller to serve up this partial RAID–which is a terrible idea because file system consistency checkers will run around destroying data that seems to them to be corrupted but is simply incomplete.