RAID Data Recovery
The majority of small-to-medium businesses across the globe have turned to RAID-configured systems for their storage solutions. The most frequently cited reasons for utilizing RAID Arrays in businesses today are the highly fault-tolerant level the solution offers and the cost effectiveness of acquisition and maintenance.
However, if a RAID Array fails as a result of component malfunctions (including hard drives and controller cards) or operating and application corruption, it leaves the data unusable and in most cases corrupted.
RAID data recovery is an intricate task since RAID data configurations often have different data layouts depending on manufacturers – often for competitive reasons. Without an in-depth knowledge of how RAID arrays are configured at hardware, firmware and software levels, data recovery attempts will not only fail, but result in further data corruption.
Using our vast knowledge of RAID Array storage technology, We can successfully recover data from the very earliest to most recent NAS, SAN and Server RAID configurations in the market.
RAID servers and configurations supported include:
Why RAID Arrays Fail
There are four general categories around failure: hardward RAID
failure, human error, software RAID failure, and application
RAID 0 (block-level
mirroring) has no (or zero) redundancy. It provides improved performance and
additional storage but no fault tolerance. Any drive failure destroys the array,
and the likelihood of failure increases with more drives in the array.
In a RAID 0 system data are split up in blocks that get written
across all the drives in the array. By using multiple disks (at least 2)
at the same time, this offers superior I/O performance. This performance
can be enhanced further by using multiple controllers, ideally one
controller per disk.
RAID 0 is not fault-tolerant. If one disk fails, all data in the RAID
0 array are lost. It should not be used on mission-critical systems.
RAID 0 is ideal for non-critical storage of data that have to be
read/written at a high speed, such as on a Photoshop image retouching
In RAID 1 (mirroring without parity or striping), data is written
identically to two drives, thereby producing a "mirrored set"; the read request
is serviced by either of the two drives containing the requested data, whichever
one involves least
seek time plus
rotational latency. Similarly, a write request updates the stripes of both
drives. The write performance depends on the slower of the two writes (i.e. the
one that involves larger
seek time and
rotational latency). At least two drives are required to constitute such an
array. While more constituent drives may be employed, many implementations deal
with a maximum of only two. The array continues to operate as long as at least
one drive is functioning.
Data are stored twice by writing them to both the data disk (or set
of data disks) and a mirror disk (or set of disks) . If a disk fails,
the controller uses either the data drive or the mirror drive for data
recovery and continues operation. You need at least 2 disks for a RAID 1
RAID 1 systems are often combined with RAID 0 to improve performance.
Such a system is sometimes referred to by the combined number: a RAID 10
RAID-1 is ideal for mission critical storage, for instance for
accounting systems. It is also suitable for small servers in which only
two disks will be used.
In RAID 2 (bit-level striping with dedicated Hamming-code parity), all
disk spindle rotation is synchronized, and data is striped such that each
sequential bit is on
a different drive.
Hamming-code parity is calculated across corresponding bits and stored on at
least one parity drive.
This theoretical RAID level is not used in practice.
In RAID 3 (byte-level striping with dedicated parity), all disk
spindle rotation is synchronized, and data are striped so each sequential
byte is on a
different drive. Parity is calculated across corresponding bytes and stored on a
dedicated parity drive.
Although implementations exist,
RAID 3 is not commonly used in practice.
On RAID 3 systems, data blocks are subdivided (striped) and written
in parallel on two or more drives. An additional drive stores parity
information. You need at least 3 disks for a RAID 3 array.
Since parity is used, a RAID 3 stripe set can withstand a single disk
failure without losing data or access to data.
RAID 3 is not that common in prepress.
RAID 4 (block-level striping with dedicated parity) is equivalent to
RAID 5 (see below) except that all parity data are stored on a single drive. In
this arrangement files may be distributed among multiple drives. Each drive
operates independently, allowing I/O requests to be performed in parallel.[citation
RAID 4 was previously used primarily by
NetApp, but has
now been largely replaced by an implementation of RAID 6 (RAID-DP).
RAID 5 (block-level striping with distributed parity) distributes
parity along with the data and requires all drives but one to be present to
operate; the array is not destroyed by a single drive failure. Upon drive
failure, any subsequent reads can be calculated from the distributed parity such
that the drive failure is masked from the end user. RAID 5 requires at least
RAID 5 is the most common secure RAID level. It is similar to RAID-3
except that data are transferred to disks by independent read and write
operations (not in parallel). The data chunks that are written are also
larger. Instead of a dedicated parity disk, parity information is spread
across all the drives. You need at least 3 disks for a RAID 5 array.
A RAID 5 array can withstand a single disk failure without losing data
or access to data. Although RAID 5 can be achieved in software, a
hardware controller is recommended. Often extra cache memory is used on
these controllers to improve the write performance.
Read data transactions are very fast while write data transaction are
somewhat slower (due to the parity that has to be calculated).
RAID 5 is a good all-round system that combines efficient storage
with excellent security and decent performance. It is ideal for file and
RAID 6 (block-level striping with double distributed parity) provides
fault tolerance up to two failed drives. This makes larger RAID groups more
practical, especially for high-availability systems. This becomes increasingly
important as large-capacity drives lengthen the time needed to recover from the
failure of a single drive. Like RAID 5, a single drive failure results in
reduced performance of the entire array until the failed drive has been replaced
and the associated data rebuilt.
In RAID 10, often referred to as RAID 1+0 (mirroring and
striping), data is written in stripes across primary disks that have been
mirrored to the secondary disks.
RAID 10 combines the advantages (and disadvantages) of RAID 0 and
RAID 1 in one single system. It provides security by mirroring all data
on a secondary set of disks (disk 3 and 4 in the drawing below) while
using striping across each set of disks to speed up data transfers.
These levels do exist but are not that common, at least not in
prepress environments. This is just a simple introduction to
RAID-system. You can find more in-depth information on the pages of
All RAID levels except RAID 0 offer protection from a single drive
failure. A RAID 6 system even survives 2 disks dying simultaneously. For
complete security you do still need to back-up the data from a RAID
The following table provides an overview of some considerations for standard
RAID levels. In each case:
* Assumes hardware is fast enough to support
** Assumes a non-degenerate minimum number of drives
*** Assumes independent, identical rate of failure amongst drives
**** Raid 10 can only lose 1 drive per span up to the max of 2/n drives
***** Theoretical maximum, as low as 1X in practice
In what was originally termed hybrid RAID,
many storage controllers allow RAID levels to be nested. The elements of a
RAID may be either individual drives or RAIDs themselves. However, if a RAID
is itself an element of a larger RAID, it is unusual for its elements to be
As there is no basic RAID level numbered larger than 9, nested RAIDs are
usually clearly described by attaching the numbers indicating the RAID levels,
sometimes with a "+" in between. The order of the digits in a nested RAID
designation is the order in which the nested array is built: For a RAID 1+0,
drives are first combined into multiple level 1 RAIDs that are themselves
treated as single drives to be combined into a single RAID 0; the reverse
structure is also possible (RAID 0+1).[citation
The final RAID is known as the top array. When the top array is a RAID 0
(such as in RAID 1+0 and RAID 5+0), most vendors omit the "+" (yielding RAID 10
and RAID 50, respectively).
Many RAID levels employ an error protection scheme called "parity", a widely
used method in information technology to provide fault tolerance in a given set
of data. Most use the simple
parity described in this section, but RAID 6 uses two separate parities based
respectively on addition and multiplication in a particular Galois Field or
Reed–Solomon error correction.
Many configurations other than the basic numbered RAID levels are possible,
and many companies, organizations, and groups have created their own
non-standard configurations, in many cases designed to meet the specialized
needs of a small niche group. Most non-standard RAID levels are
A RAID system used as
secondary storage is not an alternative to
data. In RAID levels > 0, a RAID protects from catastrophic data loss caused by
physical damage or errors on a single drive within the array (or two drives in,
say, RAID 6). However, a true backup system has other important features such as
the ability to restore an earlier version of data, which is needed both to
software errors that write unwanted data to secondary storage, and also to
and malicious data deletion. A RAID can be overwhelmed by catastrophic failure
that exceeds its recovery capacity and, of course, the entire array is at risk
of physical damage by fire, natural disaster, and human forces, while backups
can be stored off-site. A RAID is also vulnerable to controller failure because
it is not always possible to migrate a RAID to a new, different controller
without data loss.
The distribution of data across multiple drives can be managed either by
computer hardware or by
software. A software solution may be part of the operating system, or it may
be part of the firmware and drivers supplied with a hardware RAID controller.
implementations are now provided by many
operating systems. Software RAID can be implemented as:
Server class operating systems typically provide
logical volume management, which allows a system to use logical[jargon]
volumes which can be resized or moved. Often, features like RAID or snapshots
are also supported.
systems are designed to organize data across multiple storage devices
directly (without needing the help of a third-party logical volume manager).
Many operating systems provide basic RAID functionality independently of
Over time, the increase in commodity CPU speed has been consistently greater
than the increase in drive throughput;
the percentage of host CPU time required to saturate a given number of drives
has decreased. For instance, under 100% usage of a single core on a 2.1 GHz
Intel "Core2" CPU, the Linux software RAID subsystem (md) as of version
2.6.26 is capable of calculating parity information at 6 GB/s; however, a
three-drive RAID 5 array using drives capable of sustaining a write operation at
100 MB/s only requires parity to be calculated at the rate of 200 MB/s, which
requires the resources of just over 3% of a single CPU core.
Another concern with software implementations is the process of booting the
associated operating system. For instance, consider a computer being booted from
a RAID 1 (mirrored drives); if the first drive in the RAID 1 fails, then a
first-stage boot loader might not be sophisticated enough to attempt loading
second-stage boot loader from the second drive as a fallback. The
second-stage boot loader for FreeBSD is capable of loading a
kernel from a RAID 1.
controllers use proprietary data layouts, so it is not usually
possible to span controllers from different manufacturers.[citation
needed] They do not require processor resources, the BIOS
can boot from them, and tighter integration with the device driver may offer
better error handling.
On a desktop system, a hardware RAID controller may be an
expansion card connected to a bus (e.g.
a component integrated into the
motherboard; there are controllers for supporting most types of drive
technology, such as
Channel, and sometimes even a combination. The controller and drives may be
in a stand-alone
enclosure, rather than inside a computer, and the enclosure may be
directly attached to a computer, or connected via a
A RAID implemented at the level of an operating system is not always
compatible with the system's boot process, and it is generally impractical for
desktop versions of Windows (as described above). However, hardware RAID
controllers are expensive and proprietary. To fill this gap, cheap "RAID
controllers" were introduced that do not contain a dedicated RAID controller
chip, but simply a standard drive controller chip with special firmware and
drivers; during early stage bootup, the RAID is implemented by the firmware, and
once the operating system has been more completely loaded, then the drivers take
over control. Consequently, such controllers may not work when driver support is
not available for the host operating system.
Data scrubbing is periodic reading and checking by the RAID controller of all
the blocks in a RAID, including those not otherwise accessed. This allows bad
blocks to be detected before they are used.
An alternate name for this is patrol read. This is defined as a check
for bad blocks on each storage device in an array, but which also uses the
redundancy of the array to recover bad blocks on a single drive and reassign the
recovered data to spare blocks elsewhere on the drive.
In practice, the drives are often the same age (with similar wear) and
subject to the same environment. Since many drive failures are due to mechanical
issues (which are more likely on older drives), this violates those assumptions;
failures are in fact statistically correlated.
In practice, the chances of a second failure before the first has been recovered
(causing data loss) is not as unlikely as four random failures. In a study
including about 100,000 drives, the probability of two drives in the same
cluster failing within one hour was observed to be four times larger than was
predicted by the
exponential statistical distribution which characterizes processes in which
events occur continuously and independently at a constant average rate. The
probability of two failures within the same 10-hour period was twice as large as
that which was predicted by an exponential distribution.
A common assumption is that "server-grade" drives fail less frequently than
consumer-grade drives. Two independent studies (one by
Carnegie Mellon University and the other by
shown that the "grade" of a drive does not relate to the drive's failure rate.
Unrecoverable Read Errors present as sector read failures. The UBE
(Unrecoverable Bit Error) rate is typically specified at 1 bit in 1015
for enterprise class drives (SCSI,
SAS), and 1 bit in 1014 for desktop class drives (IDE/ATA/PATA,
SATA). Increasing drive capacities and large RAID 5 redundancy groups have led
to an increasing inability to successfully rebuild a RAID group after a drive
failure because an unrecoverable sector is found on the remaining drives.
Parity schemes such as RAID 5 when rebuilding are particularly prone to the
effects of UREs as they will affect not only the sector where they occur but
also reconstructed blocks using that sector for parity computation; typically an
URE during a RAID 5 rebuild will lead to a complete rebuild failure.
Double protection schemes such as RAID 6 are attempting to address this
issue, but suffer from a very high write penalty. Non-parity (mirrored) schemes
such as RAID 10 have a lower risk from UREs.
Background scrubbing can be used to detect and recover from UREs (which are
latent and invisibly compensated for dynamically by the RAID controller) as a
background process, by reconstruction from the redundant RAID data and then
re-writing and re-mapping to a new sector; and so reduce the risk of
double-failures to the RAID system
(see Data scrubbing above).
Drive capacity has grown at a much faster rate than transfer speed, and error
rates have only fallen a little in comparison. Therefore, larger capacity drives
may take hours, if not days, to rebuild. The re-build time is also limited if
the entire array is still in operation at reduced capacity.
Given a RAID with only one drive of redundancy (RAIDs 3, 4, and 5), a second
failure would cause complete failure of the array. Even though individual
mean time between failure (MTBF) have increased over time, this increase has
not kept pace with the increased storage capacity of the drives. The time to
rebuild the array after a single drive failure, as well as the chance of a
second failure during a rebuild, have increased over time.
Mirroring schemes such as RAID 10 have a bounded recovery time as they require
the copy of a single failed drive, compared with parity schemes such as RAID 6
which require the copy of all blocks of the drives in an array set. Triple
parity schemes, or triple mirroring, have been suggested as one approach to
improve resilience to an additional drive failure during this large rebuild
A system crash or other interruption of a write operation can result in
states where the parity is inconsistent with the data due to non-atomicity of
the write process, such that the parity cannot be used for recovery in the case
of a disk failure (the so-called
RAID 5 write hole).
This is a little understood and rarely mentioned failure mode for redundant
storage systems that do not utilize transactional features. Database researcher
Jim Gray wrote "Update in Place is a Poison Apple" during the early days of
relational database commercialization.
The RAID write hole is a known data corruption issue in older and low-end
RAIDs, caused by interrupted destaging of writes to disk.
A concern about write cache reliability exists, specifically regarding
devices equipped with a write-back cache—a caching system which reports the data
as written as soon as it is written to cache, as opposed to the non-volatile
Many modern drives have internal error recovery algorithms that can take
upwards of a minute to recover and re-map data that the drive fails to read
easily. Frequently, a RAID controller is configured to drop a component
drive (that is, to assume a component drive has failed) if the drive has been
unresponsive for 8 seconds or so; this might cause the array controller to drop
a good drive because that drive has not been given enough time to complete its
internal error recovery procedure. Consequently, desktop drives can be quite
risky when used in a RAID, and so-called enterprise class drives limit
this error recovery time in order to obviate the problem.
A fix specific to Western Digital's desktop drives used to be known: A
utility called WDTLER.exe could limit a drive's error recovery time; the utility
TLER (time limited error recovery), which limits the error recovery time to
7 seconds. Around September 2009, Western Digital disabled this feature in their
desktop drives (e.g. the Caviar Black line), making such drives unsuitable for
use in a RAID.
However, Western Digital enterprise class drives are shipped from the factory
with TLER enabled. Similar technologies are used by Seagate, Samsung, and
Hitachi. Of course, for non-RAID usage, an enterprise class drive with a short
error recovery timeout that cannot be changed is therefore less suitable than a
In late 2010, the
Smartmontools program began supporting the configuration of ATA Error
Recovery Control, allowing the tool to configure many desktop class hard drives
for use in a RAID.
While RAID may protect against physical drive failure, the data are still
exposed to operator, software, hardware, and virus destruction. Many studies
cite operator fault as the most common source of malfunction,
such as a server operator replacing the incorrect drive in a faulty RAID, and
disabling the system (even temporarily) in the process.
Rebuilding a RAID 5 array after a failure will add additional stress to all
of the working drives, because every area on every disc marked as being "in use"
must be read to rebuild the redundancy that has been lost. If drives are close
to failure, the stress of rebuilding the array can be enough to cause another
drive to fail before the rebuild has been finished, and even more so if the
server is still accessing the drives to provide data to clients, users,
applications, etc. Even without complete loss of an additional drive during
rebuild, an unrecoverable read error (URE) is likely for large arrays which will
typically lead to a failed rebuild.
Thus, it is during this rebuild of the "missing" drive that the entire RAID 5
array is at risk of a catastrophic failure. The rebuild of an array on a busy
and large system can take hours and sometimes days.
Therefore, it is not surprising that, when systems need to be highly available
and highly reliable or fault tolerant, other levels, including RAID 6 or RAID
10, are chosen.
With a RAID 6 array, using drives from multiple sources and manufacturers, it
is possible to mitigate most of the problems associated with RAID 5. The larger
the drive capacities and the larger the array size, the more important it
becomes to choose RAID 6 instead of RAID 5.
RAID 10 also minimises these problems.
As of August 2012, Dell, Hitachi, Seagate, Netapp, EMC, HDS, SUN Fishworks
and IBM have current advisories against the use of RAID 5 with high capacity
drives and in large arrays.