RAID 60 Data Recovery Services
RAID 60 stripes across multiple RAID 6 sub-arrays, combining dual-parity fault tolerance per span with striped throughput. When one span degrades beyond its two-drive tolerance, the stripe layer takes the entire volume offline. We recover RAID 60 arrays by imaging every member through write-blocked channels, identifying span boundaries, reconstructing each sub-array independently, and assembling the cross-span stripe from cloned images. No data, no charge.
How is a RAID 60 array structured?
Drive Count and Layout
- Minimum 8 drives: two spans of four. Each span must contain at least four members to support RAID 6 (two data + two parity).
- Typical production deployments use 12 to 24 drives across three or four spans. A 24-drive array with four spans of six yields 16 drives of usable capacity (each span loses two to parity).
- Adding spans increases sequential throughput linearly (more parallel I/O paths) at the cost of additional parity overhead and recovery complexity.
Fault Tolerance Per Span
- Each RAID 6 span tolerates two simultaneous drive failures independently. A four-span array can lose up to eight drives total, provided the failures distribute across spans.
- If a third drive fails within any single span before that span completes its rebuild, the span loses all parity protection. The RAID 0 stripe layer cannot compensate; the entire volume goes offline.
- Usable capacity = (drives per span - 2) x number of spans x smallest member size.
Why do enterprises deploy RAID 60 over RAID 6?
Database Servers
SQL Server and Oracle instances on Dell PowerEdge R740xd or HP ProLiant DL380 Gen10 servers use RAID 60 across 12 to 24 SAS drives. The striped spans provide the IOPS density that single-span RAID 6 cannot match for transactional workloads.
Virtualization Hosts
VMware ESXi and Hyper-V hosts running 50+ VMs need both the fault tolerance and the parallel I/O paths that RAID 60 provides. A single RAID 6 with 24 drives creates excessive rebuild times; splitting into four 6-drive spans limits each rebuild to four-drive reads instead of 23.
Video Surveillance
Large-scale surveillance systems writing 200+ camera feeds continuously require sustained sequential write throughput that RAID 60 delivers through its parallel span architecture. The dual-parity per span ensures footage survives drive failures without interrupting recording.
Why do RAID 60 rebuilds fail on 18 TB+ drives?
- A six-drive span with 18 TB members requires reading five surviving drives in parallel during a single-drive rebuild, with each surviving drive read in full. At a sustained 150 MB/s per drive, the arithmetic minimum is roughly 33 hours. When controller background priority or concurrent production I/O throttles per-drive throughput closer to 70 MB/s, the same rebuild stretches past 72 hours, assuming no retries or bad sectors.
- With 20 TB Ultrastar HC560 drives under throttled production throughput, rebuild time stretches well past 96 hours. The surviving drives in that span have been running for the same number of power-on hours as the one that already failed. Each additional hour of sustained sequential reads increases the probability of a latent sector error or secondary head failure.
- If the array loses one drive per span and both spans attempt simultaneous rebuilds (common with hot spares configured per span), the controller's I/O scheduler splits bandwidth between rebuild traffic and production I/O. Rebuild times double or triple under production load.
- RAID 60's per-span isolation limits rebuild scope compared to a monolithic RAID 6. A 24-drive RAID 60 with four 6-drive spans only rebuilds within the affected span (five-drive read). The same 24 drives in a flat RAID 6 would require reading all 23 surviving members, an order of magnitude more I/O exposure.
Critical: If your RAID 60 array shows a degraded span, do not force a rebuild on aging drives with high power-on hours. Power down the system, label each drive with its bay position and span assignment, and contact us. Offline imaging eliminates the rebuild risk entirely.
Controller-Specific RAID 60 Implementations
Dell PERC H740P / H755
The PERC H740P supports RAID 60 and can address up to 255 physical devices through SAS expanders, though an individual virtual disk is typically constrained to 32 members total. Span membership is recorded in DDF (Disk Data Format) metadata headers on each member.
When one drive drops out of a span and rejoins with a stale timestamp, the controller marks it "Foreign." Importing a foreign config with stale data forces a backward resync that overwrites current blocks with outdated data across every stripe changed while the drive was absent.
We image all members, inspect DDF headers in a hex editor to identify epoch timestamps per drive, and determine span boundaries before any assembly decision. This prevents the stale-member resync failure that is the most common cause of PERC RAID 60 data destruction.
Broadcom MegaRAID 9460-16i
The MegaRAID 9460-16i handles RAID 60 with up to 240 drives and supports spanning across multiple enclosures via SAS expanders. The controller writes its own DDF metadata plus a proprietary MegaRAID configuration record to each member. Recovery from this controller requires parsing both metadata layers to correctly identify span membership, because the DDF layer may reference physical enclosure positions that changed if drives were reseated during troubleshooting.
Data Extractor Express RAID Edition includes a MegaRAID metadata parser that reads both DDF and proprietary records from cloned images. When metadata is partially corrupted (common after firmware crashes), we fall back to raw data continuity analysis across member images to determine span boundaries.
HP Smart Array P408i-a / P816i-a
HP Smart Array controllers on Gen10 ProLiant servers support RAID 60 but store configuration in a proprietary format distinct from the DDF standard used by Dell and Broadcom. The controller writes span membership to a proprietary RIS (RAID Information Sector) region, typically housed in a reserved partition on each member drive.
When the Smart Storage Battery fails (POST Error 313 on Gen9/Gen10), cached writes may be trapped in the volatile cache, and the controller may refuse to present the virtual disk until the battery is replaced or the cache is manually flushed.
We bypass the controller by imaging each member drive directly via HBA passthrough, reading the RIS metadata from each image, and reconstructing the RAID 60 in Data Extractor Express RAID Edition using the parsed span map. For cache-trapped writes, we power the cache module independently to flush pending data before imaging.
Our RAID 60 Recovery Process
- Free evaluation and span mapping: Document the controller type, total drive count, span count, drives per span, stripe size, and parity rotation. If you have screenshots of the controller BIOS (PERC Configuration Utility, MegaRAID WebBIOS, Smart Storage Administrator), these accelerate parameter detection.
- Write-blocked forensic imaging: Every member drive is connected to PC-3000 or DeepSpar hardware through a write-blocked channel. We clone the full LBA range of each member, including reserved sectors where controller metadata is stored. Drives with mechanical failures receive head swaps or motor work on our 0.02 µm filtered clean bench before imaging.
- Span boundary identification: Using controller metadata parsed from the cloned images, we map which drives belong to each RAID 6 sub-array. When metadata is damaged or missing, we analyze data continuity patterns across member images to determine span membership empirically.
- Per-span RAID 6 reconstruction: Each span is reconstructed independently using Data Extractor Express RAID Edition. We identify the stripe block size, P and Q parity rotation patterns, and member ordering within each span. Both parity calculations are validated against sample stripes before the span is marked as reconstructed.
- Cross-span RAID 0 stripe assembly: The reconstructed span images are loaded as virtual drives and striped according to the controller's cross-span configuration. We verify the assembled volume by checking filesystem superblocks, partition tables, and directory structures.
- Filesystem extraction and delivery: The virtual array is parsed (NTFS, EXT4, XFS, ZFS, VMFS) using R-Studio or UFS Explorer. Files are extracted to verified target media. You receive a file listing for review before final delivery.
What Causes RAID 60 to Fail Despite Dual Parity?
Three+ Failures in One Span
RAID 60's fault tolerance is per-span, not per-array. If three drives fail in the same span (common when drives are from the same manufacturing batch with identical wear), that span loses all parity protection. The RAID 0 stripe layer treats the span as a missing stripe member, and the entire volume becomes inaccessible. Recovery from this scenario requires partial reconstruction using whatever parity data remains on the surviving drives within the affected span.
Controller Firmware Corruption
A firmware crash or bad flash on the RAID controller can corrupt the on-disk metadata that defines span membership. Without valid metadata, the controller cannot present the virtual disk, even though every member drive is physically healthy. Recovery requires parsing whatever metadata fragments survive on each member image and filling gaps through raw data analysis.
Extended Rebuild with Cross-Span Failures
When two spans each lose one drive simultaneously, both spans enter degraded mode and begin parallel rebuilds. The controller splits I/O bandwidth between production traffic and two concurrent rebuild streams. If a second drive fails in either span during this extended rebuild window, that span crosses its parity threshold. The combination of heat, vibration, and sustained I/O load on aging drives makes this outcome more likely on arrays that have been in production for 3+ years.
Accidental Foreign Config Import
On Dell PERC controllers, importing a foreign configuration with stale member data forces the controller to resync the array backward, overwriting current data with outdated blocks. On RAID 60 arrays, this affects every span that contained the stale member. The same trap applies to Broadcom MegaRAID controllers when accepting a "consistency check" prompt after drive reseating.
Why do SMR drives and write-cache dropouts abort RAID 60 rebuilds?
SMR drive ejection during sustained rebuild writes
Shingled Magnetic Recording drives absorb incoming writes into a small Conventional Magnetic Recording media cache before laying them down as overlapping shingled tracks. A RAID 60 rebuild generates uninterrupted sequential writes across the rebuilding span. That traffic overflows the CMR cache, and the drive firmware halts host I/O to perform background reshingling. The pause runs from several seconds to several minutes.
Standard SAS and SATA controllers and the Linux kernel enforce a SCSI command timeout that defaults to roughly 30 seconds, and per-drive Error Recovery Control limits run in the same range. When the SMR stall breaches that window, the SCSI Error Handling layer or the hardware RAID controller flags the member as dead and ejects it.
cat /sys/block/sdX/device/timeout # default SCSI command timeout, ~30sOn a RAID 60 this turns a survivable event into a total loss. A span that is already rebuilding has one member logically offline.
If heavy rebuild I/O stalls and ejects two or more SMR members in that span, the span crosses its two-fault threshold. Because the top layer stripes across spans, the loss of one nested span takes the entire RAID 60 volume offline.
Western Digital's general marketing message that DMSMR drives perform like CMR or show only slightly longer rebuild times runs against the SCSI-timeout reality that forces these drives out of the array mid-rebuild.
The mitigation is the same arithmetic that governs every large-drive rebuild. At the consumer rate of roughly one unrecoverable read error per 10^14 bits, about one error every 12.5 TB, a live rebuild on 18 to 20 TB members is statistically likely to hit a fatal URE before it finishes, independent of the SMR problem.
We image every member block-by-block through a write-blocked interface using ddrescue or PC-3000 hardware before any reconstruction, so an SMR stall or a URE is handled at the imaging layer and never ejects a drive from a live array.
Write-back cache dropout and torn stripes
Enterprise controllers use a DRAM write-back cache backed by a Battery Backup Unit or a Flash-Backed Write Cache supercap to acknowledge writes instantly while delaying the physical write to the platters. Dell PERC H740P/H755, Broadcom MegaRAID 9460-16i, and HP Smart Array P408i-a all carry this cache.
The prosumer parallel is the M.2 NVMe write cache on units like the Synology DS920+ and DS1621+, where a cache device dropping off the PCIe bus produces the same class of loss.
If power is lost and the BBU or FBWC has degraded or failed before the flush completes, the in-flight writes held only in volatile cache vanish. On RAID 60 the data and the P and Q parity for a stripe are written together.
Dropping the uncommitted writes leaves torn stripes, where the data blocks and the parity blocks on the platters are desynchronized, and on a multi-span array that desynchronization can land across more than one span at once.
This is one of the few outcomes where honesty requires stating a limit. Cache contents that never reached the platters are not present in any member image, so they are physically irrecoverable from cloned drives.
We reconstruct everything that was committed to the platters before the event and report the torn-stripe boundary; we do not claim to recover writes that lived only in failed cache. This is the reason RAID is availability, not data protection, and why a tested backup is the only defense against a write-back cache loss.
Critical: If a span is degraded and the array contains SMR members, power the system down. Do not force a rebuild on a degraded SMR-populated span. Label every drive by bay position and span index, and contact us for offline member-by-member imaging.
Data Extractor Express RAID Edition Workflow for Multi-Span Reconstruction
- Member image loading: All cloned member images are loaded into Data Extractor Express RAID Edition. The software scans each image for controller metadata (DDF headers, MegaRAID records, HP RIS blocks) to auto-detect span assignments.
- Span separation: Members are grouped into their respective RAID 6 sub-arrays. When auto-detection fails, we use parity signature analysis: the P and Q parity patterns within a span are mathematically distinct from data, allowing us to identify which drives share parity relationships.
- Per-span parameter detection: For each sub-array, Data Extractor Express RAID Edition detects the stripe block size (typically 64 KB or 256 KB for enterprise controllers), parity rotation direction (left-symmetric, left-asymmetric, right-symmetric), and P/Q parity algorithm variant. Each span may use different parameters if the controller was configured with non-uniform spans.
- Parity validation: Before assembling the stripe layer, we validate P and Q parity consistency across sample stripes in each sub-array. Inconsistencies indicate a misidentified member or incorrect rotation, which we correct before proceeding.
- Cross-span stripe assembly: The reconstructed sub-array images are treated as virtual drives and striped according to the detected cross-span stripe size and ordering.
- Filesystem verification: The assembled virtual volume is checked for valid filesystem structures (MBR/GPT partition table, NTFS MFT, EXT4 superblock, ZFS uberblock, VMFS volume header). A valid parse confirms the reconstruction parameters are correct.
How does RAID 60 dual-parity reconstruction work?
Every RAID 6 span carries two parity blocks so it can survive losing two members at once. The first block, P, is a plain exclusive-or across the data blocks in the stripe (P = a XOR b XOR c XOR d XOR e). That is the same single-parity arithmetic a RAID 5 uses. A RAID 5 has no Q block, so it tolerates only one missing member: with a single unknown, XOR alone reconstructs the lost block.
Any RAID 5 rebuild on a degraded array still has to read every surviving member in full, and on arrays past roughly 12.5 TB an unrecoverable read error during that pass is statistically likely, which is why we image member-by-member before any rebuild rather than letting a controller retry against live drives.
The second block, Q, is what separates RAID 6 from RAID 5. Q is a Reed-Solomon code computed with a generator over the finite field GF(2^8), so every parity byte stays inside 0 to 255 (one byte) instead of overflowing as the stripe grows.
Inside that field, addition and multiplication are redefined modulo an irreducible polynomial, which keeps the result bounded. The arithmetic resembles Q = 1·a + 2·b + 3·c + 4·d + 5·e, where the coefficients are field elements, not ordinary integers.
Two missing members in one span is the hard case. With two lost drives there are two unknowns, so P by itself is insufficient.
Recovery means solving a small system of linear equations built from both the P and Q syndromes. Because the parity generator matrix has linearly independent rows it is invertible, so the two missing blocks come out through Galois-field multiplications against that inverse. This is forensic software work performed in Data Extractor Express RAID Edition against cloned member images, not a controller "repair" button run against the original drives.
None of that per-span GF(2^8) solve is meaningful until the outer geometry is correct. The outer RAID 0 stripe order and chunk size, together with each inner span's parity rotation, have to be identified first, either from the DDF or RIS metadata parsed out of the cloned images, or from raw data-continuity analysis when that metadata is damaged.
Apply the parity math at the wrong block offsets and every span produces garbage. So the order is fixed: identify geometry across all members, validate P and Q per span against sample stripes, then assemble the outer stripe. Reverse that order and the math has nothing valid to operate on.
The same algebra explains the cascade threshold. Losing three drives inside one span gives three unknowns against only two parity equations, P and Q, so the GF(2^8) system for that span has no solution.
The outer RAID 0 layer then treats the span as a missing stripe member and takes the whole nested volume offline, the cross-span scenario covered in the failure section above. A degraded RAID 6 span inside a RAID 60 is still solvable while two equations cover two unknowns; the entire RAID recovery workflow is built to keep it in that solvable range by imaging first and reconstructing virtually.
Working With Our Lab as an IT Department
Recovery Time and Recovery Point Reality
A RAID 60 that is still mounting degraded has a different time profile than one that is fully offline. Arrays with 8-12 healthy members and no mechanical failures typically finish in 2-4 weeks from receipt. Arrays requiring head swaps on multiple members, or donor sourcing for 18-20 TB Exos and Ultrastar drives, run 4-8 weeks.
Rush scheduling moves a case to the front of the imaging queue (+$100 rush fee to move to the front of the queue). Per-member imaging throughput is governed by the slowest drive in the set; one drive with surface damage throttles the whole batch. We quote a target completion window after the free evaluation, once every member has been inspected.
The recovery point is whatever was committed to the array before the failure. Controller write-back cache that never flushed to disk is not recoverable from the cloned images; that data lived in volatile memory on the controller module. If the Smart Storage Battery failed on an HP Gen10 before the outage, assume any writes staged for flush during that window are gone.
Chain of Custody
Every member drive is photographed on arrival with serial number, bay position label, and inbound condition. Each drive receives a case-specific asset tag that ties the physical unit to its bay assignment and span index. Imaging sessions, head swaps, motor work, and PCB repairs are logged against the asset tag. When recovered data is shipped back, the log file and inbound photographs are available on request. For customers who cannot put media on a common carrier, we coordinate hand-off to a customer-supplied courier at the Austin lab.
NDA and Procurement Terms
We sign customer-supplied mutual NDAs before any drive leaves your facility, and we review standard master service agreement language. We do not hold SOC 2, ISO 27001, HIPAA, or FIPS 140-3 attestations, and we will not claim otherwise on a procurement questionnaire. If your security review requires those attestations, the honest answer is that a single-lab data recovery shop our size does not carry them; any competitor that does should be asked for the auditor report. Payment on enterprise engagements is due after successful recovery under the no-fix-no-fee guarantee; invoice terms are handled case by case with your AP team before the array ships back.
Direct Engineer Communication
The engineer working on your array is the person answering your call. No account manager layer, no offshore triage desk, no ticket routing between a front-office CSM and a back-office technician. When you ask about parity rotation on span 3 or the epoch timestamp on the drive from bay 14, the answer comes from whoever ran the PC-3000 session. Case status updates are sent when there is a state change to report, not on a marketing cadence. For multi-site engagements (enterprise server recovery cases spanning multiple controllers), we will schedule a standing call with your infrastructure team for the duration of the case.
RAID 60 Recovery Pricing
| Cost Component | Price Range | Notes |
|---|---|---|
| Per-member imaging: logical or firmware-level issues | $250–$900 per drive | Covers filesystem corruption, firmware module damage requiring PC-3000 terminal access, and SMART threshold failures that prevent normal reads. |
| Per-member imaging: mechanical failures (head swap, motor seizure) | $1,200–$1,500 air-filled / $3,000–$4,500 helium per drive | 50% deposit required. Donor parts are consumed during the transplant. Head swaps are performed on a 0.02 µm filtered clean bench before write-blocked cloning. |
| Array reconstruction fee | Scoped per array at free evaluation | Quoted after evaluation based on span count, members per span, filesystem type, and whether parameters must be detected from raw data versus parsed from surviving metadata. Includes per-span P+Q parity validation and cross-span stripe assembly. |
Data Extractor Express RAID Edition performs span identification, per-span parameter detection, and virtual assembly from cloned member images. R-Studio and UFS Explorer handle filesystem-level extraction after the array is reconstructed.
No Data = No Charge: If we recover nothing from your array, you owe $0. Free evaluation, no obligation.
RAID 60 arrays with 16+ members or mechanical failures on multiple drives will receive a custom quote after free evaluation.
RAID 60 Recovery Questions
How many drives can fail in a RAID 60 before data is lost?
What is the minimum number of drives for RAID 60?
When should I choose RAID 60 over RAID 6?
How long does a RAID 60 rebuild take with 18 TB drives?
Why is RAID 60 recovery harder than RAID 6?
Can you recover a RAID 60 if the controller card failed?
Do you sign NDAs and work under our procurement terms?
Who inside your shop actually talks to our IT team during a recovery?
How is chain of custody documented on an enterprise RAID 60 case?
Can SMR drives cause a RAID 60 rebuild to fail?
What happens to RAID 60 data in the controller write-back cache after a power loss?
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.
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 videoRelated services
Need Recovery for Other Devices?
Degraded RAID 60? Power down before rebuilding.
Free evaluation. Offline multi-span reconstruction from cloned images. No data = no charge. Mail-in from anywhere in the U.S.