Data Recovery Weekly

If you are doing a RAID Recovery and the software has the capability to limit the allowed block sizes for search (which is quite often actually, ReclaiMe Pro has it, Runtime has it, ZAR has it, and perhaps R-Studio has too), and if you happen to know the block size exactly, do not set the limiter to exact block size. If you know the block size is 128 whatever units, set limits to 64 low and 256 high ( of the same units , repeat, the same units ). Otherwise, if the automatic detection gets you the value at one of the edges of the range, you do not know if it is because the value is correct, or because it hit the limit and was not able to further change the block size. The final block size must be inside the allowed range, not on the edge.

When someone says RAID5 is fault-tolerant , this is not meaningful enough. Specific implementation must be named.  The set of anticipated failures must be listed. For each of the anticipated failures, the extent of degradation must be specified. So, generic implementation of RAID5 does not lose data when exactly one drive fails . This does not say anything about performance and, generally, data availability. Another example is generic NAS does not lose data if its network connection fails . However, the data is unavailable until connection is fixed in some way or other. So, when talking fault tolerance, don't forget to include at least the set of anticipated failures.

Just thought I would clarify one misconception about X-RAID2. If there are two identical drives, then the array is in fact RAID1. No, not exactly. The array may be RAID1, but there are cases when there are two (or more) RAID1s, combined by LVM. This happens when a two-disk set is upgraded by replacing two drives with larger ones. If the array never had it's drives replaced, it is indeed a single RAID1.

It doesn't make sense to combine several mirrored virtual disks created in Storage Spaces to a RAID0 using Disk Management, Dynamic Disks, and LDM as described here , at least when dealing with not too many disks. Apparently, too many is more than eight disks. If you have eight disks or less, the Storage Spaces driver allocates data in such a way that you get a RAID10 consisting of four disk pairs maximum. It is pointless to impose one more RAID layout on top of this configuration; doing so you can even make the matter worse due to alignment issues. Talking about alignment, it should be noted that stripe on a Storage Spaces virtual disk is 256 KB in size and starts from the beginning of the virtual disk.

There are symmetrical (for example RAID5) and asymmetrical (like RAID4) RAID arrays. 1 2 p 3 p 4 p 5 6 RAID 5   1 2 p 3 4 p 5 6 p RAID 4 As load increases, performance of an asymmetrical array is limited in some particular point. For example, in RAID 4, during a write operation, a disk with parity will be saturated first. In case of a symmetrical RAID 5 array all the member disks are loaded in the same way; therefore there is no specific disk that limits the performance. From this two consequences follow: 1.    In a symmetrical RAID 5 array write performance can be increased by adding the disks. Write performance of asymmetrical RAID 4 doesn't change as the number of drives increases because parity...

People note that write speed on mirror or parity volumes in Storage Spaces is slower as compared to a traditional RAID1 or RAID5. Indeed, parity and mirror volumes of Storage Spaces are not identical to a regular RAID1 or RAID5 in terms of maintenance costs. The ReFS driver that manages the filesystem structure on the Storage Spaces volumes must also calculate checksums over data to avoid the write hole issue.

Once again an explanation of RAID levels, this time a fun one and by the way, drop me a note if anyone knows the author?

Modern hard drives have annual failure rate of about 5%. With this sort of the failure probability you cannot realistically talk about the simultaneous hard drive failures, even if the window of simultaneousness spans several hours. The simultaneous failure of two drives is just not probable enough. The catch is, the statistics only applies to independent drives. The common-mode failure, when several drives fail because of a single cause, is not accounted for. As a consequence of this, in fault-tolerant RAID applications more effort should be put to eliminate possible single points of failure. Realistically, this means the most effective thing you can do is to eliminate the operator, eh.

All RAID types are built using three elements: Striping Data blocks on several disks. Writing redundant data (it is usually the result of calculating particular functions). Writing multiple copies of data (usually two copies are written). Different combinations of these elements allow to get data placement patters (RAID levels) which provide desired balance between speed, reliability and price. If we only use striping, we get a RAID 0. Using only one function to calculate redundant data we will get us a RAID 5. If we add one more set of redundant data to a RAID 5, it becomes a RAID 6. We get a RAID 1 from identical copies, but if you combine the striping technique with exact copies then you get a RAID 10. These data placement patterns are the most widespread and well-known, forming a so-called raid triangle . Except these RAID types, we can also see exotic combinations. For example, if in RAID 10 we use the number of disks which is not an integral multiple of the number of data copies ...

The computer with Asus motherboard based on ICH8R has worked flawlessly for about 1.5 years. Two 250 GB hard disks were in RAID1 divided into two partitions. Two weeks ago I heard about a problem (the request to press a key when loading) which don't lead to subsequent problems in the operation. When the system is starting up, the message "Primary HDD not found. Press F1 to resume" is displayed. Pressing F1 leads to usual system start with the message "New device was found ...". When I started to sort out what happened I found out that RAID controller switched over to IDE mode. Disk Management displayed copies of logical disks (originally there were C:, D:, -- but now E: and F: are added with the same sizes and labels). The freshest file dates on the copies coincided with the date when start up problems arose. When I switched the controller to RAID, RAID1 appeared immediately with the name specified by me in RAID settings. The state of RAID 1 was shown as "N...

If you are reconfiguring a RAID, or whatever other storage system, and something unexpected happens, or something happens that you do not fully understand, stop. Pressing on in this situation would likely make things worse. Pressing on for long enough will eventually make things irreversibly bad. This thread on Tom's presents a good example. When reading it, keep in mind two things, Even if one do not initialize the RAID, each time RAID 10 is reassembled and resynched with different order of disks, there is a 50:50 chance of total data loss Repairing a filesystem or troubleshooting boot process without having fixed an underlying RAID first is certainly useless and often damages the data.

in a RAID 6? Actually, yes. All it takes is large number of disks in array, intensive I/O, a power failure, and some bad luck.

I'm getting tired of people advocating RAID 5 vs. RAID 6. They go on like oh, in a RAID 5 a bit error URE will get you one day! We spent 10,000s dollars sending our RAID5s to OnTrack. Yes, that's tens of thousands of Uncle Sam Dollars. Single bit error in a RAID 5 is much cheaper to recover from than a RAID 6 controller failure or an operator accidentally deleting the array. Ever asked for a quote on RAID 6 recovery?

Some do actually like non-standard hardware and software setups. If we build a 16 TB RAID 5 (9x 2TB), can we then install Windows on it? Probably yes, with some U/EFI trickery, but then troubleshooting this contraption if hardware ever dies would be a nightmare with 9 drives. Now another try We have a leftover of drives, like all sorts of 160GB to 2TB Parallel ATA, all sorts of Serial ATA, five RAID/HBA controllers, and a motherboard. We thought of putting it all together and deploying ZFS over it. Do you think it is a good idea? Actually, no. The complexity of the failure modes for the proposed design is just mind-boggling. First of all, when ZFS crashes, there is no reliable data recovery for it. Then, multiple HBA/RAID cards from different vendors in the same system are not going to work stable. More then, with a different size drives, no common RAID scheme can be applied. Should the RAID fail, the system is not recoverable. OK you can go with ZFS hybrid filesystem-RAID capability, ...

If there is a set of disks, but the RAID type is not known, how do we determine what type of RAID is that? Most of the RAID recovery programs, including ours at www.FreeRaidRecovery.com , require the RAID type to be provided by the operator. In a most simple case, where all disks are available, one can get the idea of the RAID type by just plugging all the disks and looking at the Disk Management data. The following cases are most typical, 1. One or multiple partitions on exactly one of the disks. This is a RAID 0 or a RAID 5, more likely RAID 0. 2. One or multiple partitions, with two identical sets of partitions on two disks. With three disks, this is a RAID 5. With four or more disks, this is either a RAID 5 or a RAID 10. The above does not account for RAID 6 or exotics like RAID 3, and assumes MBR-style partitioning on the array, but nevertheless makes for a good start when working with an array of unknown type.

A full, start-to-end RAID recovery is generally a three part process. Determine status of the member disks and make clones when required. Detect RAID parameters and perform destriping If the destriped volume is not readily mountable, perform filesystem recovery on it to pump out the data Now, if the above three steps fail to produce correct data, the question is how do we tell if it is RAID recovery part, or filesystem analysis part that failed ? We tell if the RAID recovery is OK by looking at the sizes of the recovered files. If there are multiple good files recovered which are larger than twice the full row size (i.e. larger than 2 * block_size * num_disks), then the RAID recovery is almost certainly OK. However, if all good files are of the small size, the RAID parameters should be investigated. This also applies to the files found by raw scan; however, keep in mind that file sizes produced by raw scan are not reliable.

... that one does a rebuild with the wrong order of disks. This is by far the most common scenario we at www.FreeRaidRecovery.com have for an unrecoverable RAID 5. Something bad happens and the configuration is lost. The operator then assembles the array in a way which looks correct , and does a rebuild on it. The configuration which looks correct is just not good enough. You need a configuration which actually is correct. Doing a rebuild on a RAID 5 with wrong block size or disk order effectively destroys the data on the array. Theoretically, the data can still be restored, but practically the complexity of having two sets of parameters (with unknown block sizes, disk orders, and such) precludes any recovery.

The customer walks in and says something along the lines of you should have more input options for your RAID Recovery app . Unfortunately, it just does not work that way. As you add more options and combinations thereof, people starting to get lost among these fast. Interestingly, I recall once considering an automatic software to detect all RAIDs attached to the system with just one click of button. Something more along the lines of All your RAID are belong to us , which would eliminate the requirements both to specify array type and to select a disk set. Just do all the probing and produce all possible RAIDs. Unfortunately, this did not work out for technical reasons. Actually, even providing a correct RAID type may prove difficult if the array was created five years ago, the person setting up the system retired four years ago, and noone even noticed the RAID until it failed. So now you have four disks, some of which may or may not work; so, RAID 0, RAID 10, RAID 5, or RAID 6? ...

A customer walks in and says: We need to recover a FATX volume, can you do that? - Sorry, no. Various exotic filesystems, btrfs, logfs, and even ReiserFs have always been considered a job for a data recovery serivce, not an automated software. Software is cheap, but only resolves common cases by applying typical solutions. Data recovery service is expensive, and applies its high fees toward the difficult cases, e.g. writing custom software to deal with just one specific case. Lately, there is an influx of requests for something nonstandard. The latest hit was - We have ReiserFs on the RAID5. - Okay, no problem. Turns out there was a problem. The RAID5 was using 512 bytes per block. JMB 393 controller. Oops. So far we have delayed parity (from HP SmartArray), Promise RAID 6 with its non-standard Reed-Solomon, Promise 1E interleaved layout, exFAT filesystem recovery . The capability to recover RAID with a block size of 512 bytes is in the pipeline, currently undergoing testi...

Every once in a while, we get a feature request for our RAID recovery software ( http://www.freeraidrecovery.com/ ) to implement the ability to interrupt the analysis midway and get a list of possible solutions, sorted by confidence level . There is some strong reservation against this would-be feature. Although it looks like a good idea, a very nice thing to have, it has some undesired consequences we cannot allow. The confidence thresholds are there for reason, and we put an effort to ensure they are balanced between faster analysis (lower thresholds) and reliability (higher thresholds). Once we make incomplete solutions accessible, people will start using these solutions on real data. Sooner than later, someone is going to destroy their RAID 5 by reassembling it on the controller using wrong parameters set. In RAID0, this would be no harm (just re-assemble again in correct order), but with RAID 5, incorrect assembly (automatically followed by a rebuild) destroys the array beyo...