Degraded RAID Array: Safe Troubleshooting Before You Rebuild

What Degraded Means03/11

What a Degraded RAID Array Actually Means

A degraded array is still operational but has lost its redundancy. It is running on borrowed time. The array can serve reads and writes, but a second drive failure will exceed the fault tolerance of most RAID levels.

The RAID controller detects that a member drive has stopped responding, is returning errors, or has been physically removed.
The controller marks the drive as failed and continues operating using the remaining drives and parity data (RAID 5/6) or the surviving mirror (RAID 1/10).
Read performance drops because the controller must compute the missing data for every stripe that included the failed drive.
Write performance may also decrease because parity updates now require reading additional blocks for the XOR calculation.
The array remains in this state until a replacement drive is inserted and the rebuild completes, or until a second drive fails.

Example: An 8-drive RAID 5 array has one drive report a SMART predictive failure. The controller marks it as failed and transitions the virtual disk to "Degraded." The server continues serving the file share. Users notice slower access times on large files because every read from a stripe that included the failed drive now requires the controller to XOR the remaining 7 drives to compute the missing data.

Degraded States Across RAID Levels04/11

How Does Degraded State Differ Across RAID Levels?

The consequences of a degraded state depend on the RAID level. RAID 5 has zero remaining margin. RAID 6 can survive one more failure. RAID 10 depends on which mirror pair lost a drive.

RAID Level	Degraded Behavior
RAID 1 Mirror	One mirror drive failed. Data is intact on the surviving drive, completely unprotected. A failure of the remaining drive means total data loss. Recovery from degraded RAID 1 is the simplest case: the surviving drive contains a complete copy of all data.
RAID 5 recoverySingle Parity	One drive failed. Parity reconstructs the missing data on-the-fly. A complete second-drive failure during a rebuild is fatal: there is no parity left to cover a second missing member. A single URE on a surviving member loses the data in that one stripe with no parity to rebuild it; whether the whole volume then drops offline depends on the controller (legacy and HP Smart Array P/E-series abort, modern PERC and MegaRAID puncture and continue, mdadm logs and continues). No remaining margin. This is the highest-risk degraded state for arrays with large drives.
RAID 6 recoveryDual Parity	One or two drives failed. Dual parity provides one more drive of margin compared to RAID 5. A single-degraded RAID 6 can survive one more failure. A double-degraded RAID 6 is in the same position as a degraded RAID 5: zero remaining margin. Rebuild times on large arrays (10TB+ drives) can exceed 48 hours.
RAID 10 Mirrored Stripes	One drive in a mirror pair failed. The surviving mirror serves data. The array can survive additional failures as long as they occur in different mirror pairs. If the other drive in the same mirror pair fails, that stripe is lost. Rebuild of RAID 10 is faster because only the failed drive's mirror needs to be copied (not the entire array).

Example: A 6-drive RAID 10 (3 mirror pairs). Drive 2 (pair B, member 1) fails. The array is degraded but can survive failures in pair A or pair C without data loss. If drive 3 (pair B, member 2) fails, pair B has no surviving copy and the entire array loses access to that stripe. RAID 10 degraded risk is localized to the affected mirror pair.

Checking Controller Logs05/11

Checking Controller Logs Without Triggering a Rebuild

Before inserting a replacement drive, check the RAID controller logs and SMART data on all surviving drives. The goal is to identify whether any other drives are showing early failure signs before committing to a rebuild.

Hardware RAID

●Dell: OMSA (OpenManage Server Administrator) or racadm/iDRAC web interface
●HP/HPE: iLO web interface or Smart Storage Administrator (SSA)
●LSI/Broadcom: MegaCLI or StorCLI command-line utilities
●Adaptec: arcconf command-line utility or maxView web interface

Linux mdadm Software RAID

●cat /proc/mdstat shows array state and rebuild progress
●mdadm --detail /dev/mdX shows detailed array status including member drives
●smartctl -a /dev/sdX shows SMART attributes per drive
●Check for Reallocated_Sector_Ct, Current_Pending_Sector, and Offline_Uncorrectable counters above zero

Example: An 8-drive RAID 5 array has one drive show as "Failed." Before inserting a replacement, the admin checks SMART data for all remaining drives. Another drive shows multiple Reallocated Sectors and Current Pending Sectors. This drive is likely to fail during the rebuild. The admin now knows that a standard rebuild carries high risk and can make an informed decision about whether to image the drives first.

NAS appliances run the same Linux software-RAID layer underneath their web interfaces: Synology SHR is mdadm aggregating drive partitions under LVM with a Btrfs or ext4 volume on top, and QNAP QTS uses mdadm, LVM, and ext4, so the same cat /proc/mdstat and mdadm --detail checks apply over SSH before any repair. When a NAS-hosted volume drops into a degraded state, the safe path forward is the same imaging-first workflow used for NAS data recovery.

Why Auto-Rebuild Is Dangerous06/11

Why Auto-Rebuild Is Dangerous on Large Drives

Most RAID controllers are configured to begin rebuilding automatically when a hot spare is present or a new drive is inserted. On arrays with large drives (4TB and above), this default behavior is the most common cause of rebuild failures.

Auto-rebuild starts immediately, giving the administrator no opportunity to check SMART data on surviving drives.
For parity arrays (RAID 5/6), the rebuild reads every sector of every surviving drive under sustained sequential I/O. RAID 1/10 rebuilds read only the mirror partner. On aging consumer 8TB drives in a parity array, a 24TB rebuild places sustained mechanical stress on the remaining members, increasing the risk of a secondary failure or latent sector error.
Drives from the same manufacturing batch tend to fail in close succession. If one drive from a batch of 8 has failed, the remaining 7 are statistically more likely to fail under the increased load of a rebuild.
Rebuild times on large arrays can exceed 24 hours, during which the array runs with zero fault tolerance (RAID 5) and the drives experience sustained sequential I/O.

Before inserting a replacement drive: disable auto-rebuild in the controller BIOS, remove any configured hot spares, and verify SMART health on every surviving drive. For RAID data recovery service scenarios where the data is irreplaceable, image all surviving drives before the rebuild starts.

Example: A file server with 6 large-capacity drives in RAID 5 loses one drive. A hot spare activates and the rebuild begins automatically. The rebuild must read the entire capacity of the 5 surviving drives under sustained sequential I/O. This prolonged, intensive operation on aging drives with similar wear profiles creates a high risk of a secondary mechanical failure or latent sector error before the rebuild can complete.

Calculating Fault Tolerance07/11

Calculating Your Remaining Fault Tolerance

Before deciding how to respond to a degraded array, calculate how many additional failures your array can tolerate. This determines the urgency and risk of each possible action.

RAID 1: tolerates (N - 1) additional failures if N drives remain in the mirror. A 2-drive RAID 1 with one failed drive has one drive remaining and therefore zero margin.
RAID 5: tolerates exactly 0 additional failures once degraded. Any error on any surviving drive is fatal.
RAID 6: tolerates 1 additional failure once single-degraded, 0 once double-degraded.
RAID 10: tolerates additional failures only in mirror pairs that still have both members. Losing both drives in any single pair is fatal for that stripe.
Factor in the rebuild duration. A 24-hour rebuild window on drives from the same batch and age is 24 hours of elevated failure risk.

Example: A 10-drive RAID 6 with one failed drive has a remaining fault tolerance of 1 more drive. The admin checks SMART data and finds the surviving drives are from the same batch and age. Two drives show elevated reallocated sector counts. Given the large amount of data the rebuild must read and the long estimated rebuild time, the admin decides to image all 9 drives before initiating the rebuild, preserving the current degraded state as a fallback.

The URE Math08/11

Why Does a Degraded RAID 5 Rebuild Hit an Unrecoverable Read Error?

A degraded RAID 5 rebuild hits an Unrecoverable Read Error because consumer SATA drives are commonly rated for one URE per 10^14 bits read, about 12.5 TB, and recalculating parity across a large array reads far more than that. With the array already degraded there is no spare parity to recompute the affected stripe, so the controller logs the error and aborts the rebuild.

This is deterministic bit-rate arithmetic, not a quoted success rate. The URE specification is a per-bit-read rating, and a parity rebuild forces a full-capacity read across every surviving member.

A consumer SATA drive rated at one URE per 10^14 bits will, on average, return one unrecoverable sector for every 12.5 TB it reads.
Reconstructing a single failed member in RAID 5 means reading every sector of every surviving drive. On a large array that read total runs on the order of 48 TB, well past the 12.5 TB URE threshold.
Because the array is already degraded it holds zero spare parity. When the rebuild read hits a URE on a surviving member, the missing block in that stripe cannot be recomputed.
The controller logs the read error and aborts the resync. Depending on the controller, the virtual disk then drops offline rather than completing degraded.
The same sustained sequential read that triggers the URE also loads aging members from the same manufacturing batch, raising the chance a second drive drops during the rebuild window.

Shingled Magnetic Recording members compound the problem. Under the sustained sequential write of a rebuild the CMR cache zone fills and the drive pauses to reshingle; the controller reads that latency as a dead drive and ejects the healthy SMR member, turning a single-drive rebuild into a multi-drive failure.

URE (Unrecoverable Read Error): A sector a drive cannot read after exhausting its internal retries and ECC. Rated at roughly one per 10^14 bits, or about 12.5 TB, on consumer SATA drives.
SMR (Shingled Magnetic Recording): A recording method that overlaps tracks and relies on a CMR cache zone. The background reshingle pause during sustained writes can be misread by a controller as a drive failure and trigger ejection during a rebuild.
DDF (Disk Data Format): The SNIA on-disk metadata structure that lets enterprise controllers store array geometry on the member drives, so the array can be reconstructed from the disks without the original controller.

Image Every Member First09/11

How Do You Image Every RAID Member Before a Rebuild?

Image every surviving member sector-by-sector through a hardware write blocker before any rebuild, then reconstruct the array virtually from those images. The images preserve the degraded state as a fallback if the rebuild fails, so the physical drives are never written to during recovery.

Imaging and reconstruction are two separate stages. The hardware images and reads sectors from each member; the array geometry is then reconstructed in software against the image files, never against the live members.

Confirm the degraded state before touching anything. On software RAID, cat /proc/mdstat shows the array state and mdadm --detail /dev/mdX lists each member and its role.
Image every surviving member sector-by-sector through a hardware write blocker. GNU ddrescue with a mapfile lets you resume across bad areas without re-reading the whole disk:

ddrescue --force --no-scrape /dev/sdX member1.img member1.map

For weak or slow members, image on a PC-3000 Portable III or PC-3000 Express, or a DeepSpar Disk Imager, which handle slow sectors and head instability that would stall a plain ddrescue pass. The hardware reads the sectors; it does not assemble the array.
Reconstruct the array geometry virtually in software against the image files. For software RAID that is mdadm --assemble --readonly over loop devices backed by the images. For hardware-controller arrays, array-aware forensic software such as Data Extractor Express RAID Edition (the ACE Lab RAID tool that runs on the PC-3000 Express) detects chunk size, stripe order, and parity rotation from the images and assembles the array read-only.
Extract the filesystem from the virtual array to a customer-supplied destination drive. The original imaged members stay untouched, so a failed assembly attempt costs nothing and the degraded state remains available to try again.

RAID is availability, not a backup. A parity or mirror array protects uptime, not data. Accidental deletion, ransomware, a controller failure, or a cascading failure of same-batch drives destroys data across every member at once. Imaging first preserves the only copy you have; discrete offline backups are what actually protect the data.

Recovery Pricing10/11

If You Need a Recovery Lab: Pricing

When a degraded array cannot be rebuilt safely, the cost depends on the failure mode of each member drive, not on RAID level alone.

Per-drive recovery pricing on RAID member disks falls in the $100–$2,000 range. Logical-only array reconstruction on physically healthy members sits at the lower end. Recoveries that involve head swaps, donor parts, or platter work on multiple members move toward the upper end. For larger capacities (8TB, 10TB, 16TB and above), target drives cost $400+ extra. The full per-tier breakdown lives on the hard drive recovery cost page, with RAID-specific guidance on the RAID data recovery service page.

No diagnostic fees. We image and assess before quoting.
+$100 rush fee to move to the front of the queue.
No-data, no-recovery-fee guarantee. If the data cannot be returned, the recovery attempt is free.
All work performed at the Austin, TX lab. Mail-in for nationwide RAID member drives.

Faq11/11

Frequently Asked Questions

What does degraded RAID mean?

A degraded RAID array has lost one or more member drives but remains operational by computing the missing data on each read using parity (RAID 5/6) or serving from a surviving mirror (RAID 1/10). The array is functioning but has lost its fault tolerance. A second failure during degraded operation can be catastrophic for RAID 5, survivable with one more drive of margin for RAID 6, and depends on which mirror pair is affected for RAID 10.

Can a degraded RAID array still lose data?

Yes. A degraded array has no remaining redundancy (RAID 5) or reduced redundancy (RAID 6). Any additional drive failure, URE during a rebuild, or controller error can cause permanent data loss. The array is running without a safety net. The longer it operates in degraded mode, the higher the probability of a second failure due to increased I/O load on the surviving drives.

Should I replace a failed drive in a degraded RAID immediately?

Not without first understanding the risk. Inserting a replacement drive typically triggers an automatic rebuild. For parity-based arrays (RAID 5, RAID 6), this rebuild reads every sector of every surviving drive to recalculate the missing data. RAID 1 and RAID 10 rebuilds read only the surviving mirror partner. On large consumer drives (4TB+) in parity arrays, the probability of encountering an Unrecoverable Read Error during this full-disk read is high enough that the rebuild itself can cause the array to fail. For arrays containing irreplaceable data, imaging the surviving drives before initiating a rebuild is the safer approach.

Can I run a degraded RAID 5 in place?

Technically yes, the array will continue serving reads and writes while degraded, but you are running with zero fault tolerance. Every read from a stripe that included the failed drive forces the controller to XOR the remaining members to reconstruct the missing block, which increases I/O load on the surviving drives. A single URE on any one of those drives during normal operation will return bad data with no parity left to correct it. If the data is replaceable and the array is small, you can run degraded long enough to plan a maintenance window. If the data is irreplaceable, take the array offline and image the surviving members before doing anything else.

Should I let the controller auto-rebuild?

Not on a parity array containing data you cannot afford to lose. Auto-rebuild on RAID 5 or RAID 6 starts a full-array read across every surviving drive the moment a hot spare activates or a replacement is inserted. You lose the opportunity to check SMART data on the surviving members, and any drive showing reallocated sectors or pending sectors is statistically likely to fail under the sustained sequential I/O of a rebuild. Disable auto-rebuild in the controller BIOS, remove configured hot spares, verify SMART health on every surviving drive, and only then make the rebuild decision. For irreplaceable data, image first.

How much does RAID data recovery cost?

Per-drive recovery pricing on the member disks falls in the $100–$2,000 range depending on what is wrong with each drive. Logical-only RAID reconstruction on healthy members sits at the lower end of that range; recoveries involving head swaps, surface damage, or firmware work on multiple members move toward the upper end. Final cost depends on how many drives need physical work and which failure tier each one falls into. There are no diagnostic fees, and the no-data, no-recovery-fee guarantee applies. See the full breakdown at /hard-drive-data-recovery-cost.

How many bits can a consumer hard drive read before a URE?

Consumer SATA drives are commonly rated for one Unrecoverable Read Error per 10^14 bits read, which works out to roughly 12.5 TB of data. A degraded RAID 5 rebuild has to read every sector of every surviving member to recompute the missing drive, so on an array that requires reading on the order of 48 TB the bit-rate math says a URE is encountered before the rebuild finishes. Because the array is already degraded there is no spare parity to recompute the stripe the URE landed in, so the controller logs the error and aborts. This is deterministic bit-rate arithmetic, not a quoted failure percentage.

Why image RAID members before rebuilding?

Imaging every surviving member sector-by-sector before any rebuild preserves the degraded state as a fallback. A rebuild forces sustained full-capacity reads across every surviving member, and a member already carrying weak or pending sectors can fail outright under that load; if a second drive drops mid-rebuild the array can end up unmountable with no clean degraded state left to fall back on. Imaging through a hardware write blocker with ddrescue or a PC-3000 Portable III leaves the original members untouched. The array is then reconstructed virtually in software from those image files, so every rebuild attempt runs against copies and the physical drives are never put at further risk.

Is RAID a backup?

No. RAID provides hardware availability and uptime, not data protection. Accidental deletion, ransomware, a controller failure, or a cascading multi-drive failure destroys data across every parity and mirror member at once, because all members are part of the same live array. Members are typically bought from the same manufacturing batch and run in the same thermal and I/O environment, so they tend to fail in close succession under rebuild load. True data protection requires discrete, offline backups that are not part of the array.

No Data, No Fee

Guarantee

2.49M+

Subscribers

4.9

1,837+ Google Reviews

Since 2008

Established

Repairs on Video

Full Transparency

As Featured In

Data Recovery Standards & Verification

Our Austin lab operates on a transparency-first model. We use industry-standard recovery tools, including PC-3000 and DeepSpar, combined with strict environmental controls to maintain drive integrity. This approach allows us to serve clients nationwide with consistent technical standards.

Validated Clean Zone

Open-drive work is performed in a ULPA-filtered laminar-flow bench, validated to 0.02 µm particle count, verified using TSI P-Trak instrumentation.

Transparent History

Serving clients nationwide via mail-in service since 2008. Our lead engineer holds PC-3000 and HEX Akademia certifications for hard drive firmware repair and mechanical recovery.

Media Coverage

Our repair work has been covered by The Wall Street Journal and Business Insider, with CBC News reporting on our pricing transparency. Louis Rossmann has testified in Right to Repair hearings in multiple states and founded the Repair Preservation Group.

Aligned Incentives

Our "No Data, No Charge" policy means we assume the risk of the recovery attempt, not the client.

Technical Oversight

Louis Rossmann

Our engineers review all lab protocols to maintain technical accuracy and honest service. Since 2008, his focus has been on clear technical communication and accurate diagnostics rather than sales-driven explanations.

We believe in proving standards rather than just stating them. We use TSI P-Trak instrumentation to verify that clean-air benchmarks are met before any drive is opened.

See our clean bench validation data and particle test video

Related services