When a RAID array fails, the cost of downtime starts before the recovery does. Whether it’s a single-server array refusing to boot after a controller event, a NAS that won’t mount after a rebuild, or a SAN behind a virtualization cluster showing missing LUNs, the urgent question is the same: how do we get the data back, fast, without making the situation worse. Gillware has been answering that question for businesses since 2004. Our engineers reconstruct failed RAID arrays of every level — including RAID 0, 1, 5, 6, 10, 50, 60, and JBOD — from server, NAS, SAN, and virtualization deployments, in an ISO 5 Class 100 cleanroom at our SOC 2 Type II audited facility in Madison, Wisconsin. Every case starts with a free in-lab evaluation.

Start a free RAID recovery evaluation →

Stop Using the Array

The single most common way a recoverable RAID failure becomes an unrecoverable one is continued operation after the first failure. Before sending an array in for recovery:

• Power the array down. Repeated boot attempts on a degraded array compound the problem — especially on RAID 5 with one drive already failed, where a second drive can be pushed over the edge by a rebuild attempt.
• Do not attempt another rebuild. Failed rebuilds are one of the leading causes of data loss we see. If a rebuild has already failed once, a second attempt usually makes recovery harder.
• Do not run consistency checks or repair tools against a degraded or foreign array. These operations write to the disks and can destroy reconstruction metadata our engineers depend on.
• Label each drive by bay position before removing anything from the chassis. Slot order matters for reconstruction, and a misordered set of drives can add hours or days to the recovery.
• Do not run data recovery software against the raw disks. Software designed for single-disk logical recovery does not understand RAID metadata, and writes from these tools can overwrite parity blocks needed to rebuild the array.

If a drive has physically failed inside the array, leave it where it is and ship the full set together. Trying to clone or image a clicking drive outside a cleanroom is one of the fastest ways to lose the data.

RAID Failures We Recover

Most of the arrays we see fall into a handful of failure patterns. Several of these have dedicated pages with deeper detail and real-world cases.

RAID controller failure

A failed controller can take an otherwise healthy array offline by losing its configuration metadata. The drives still hold the data, but without the controller’s parameters — stripe size, drive order, parity rotation, offset — the operating system can’t see the volume. Our engineers reverse-engineer the original array parameters from on-disk metadata and reconstruct the volume in software without depending on the original controller.

Failed rebuild on a degraded array

RAID 5 with one drive already failed is the highest-risk configuration in IT. When a second drive develops read errors during the rebuild — or the rebuild simply doesn’t complete — the array can be left in a partial state that the controller refuses to mount. This is one of the most common cases we recover. More on RAID punctures and failed rebuilds →

Multiple disk failures beyond fault tolerance

A RAID 5 with two failed drives or a RAID 6 with three is, on paper, unrecoverable. In practice, one of the “failed” drives is often only marginally bad — a few unreadable sectors, a head problem, or a firmware lockup that looks like total failure to the controller. Our cleanroom engineers can often resurrect one of the degraded drives long enough to image it, restoring fault tolerance and enabling a full reconstruction.

Foreign array / array not detected

After a controller event, firmware update, or motherboard swap, the controller may mark the array as foreign or fail to detect it at all. The data on the drives is intact, but the controller has lost its ability to assemble them. More on “no volume configured” and foreign-array recoveries →

Operating system won’t boot from array

The server posts but cannot find a bootable volume, often with an “Operating System Not Found” message. The cause is usually a corrupted boot sector on the array, a damaged controller cache, or partition table loss after a power event. The data behind the boot block is typically intact and recoverable.

NAS device failures

Synology, QNAP, Netgear, Buffalo, Drobo, and FreeNAS units use proprietary on-disk layouts that don’t follow standard RAID metadata conventions. Our engineers maintain parsers for every major NAS platform and recover from failed RAID groups, crashed storage pools, and unmountable volumes regardless of vendor. Two of the most common scenarios: crashed Synology storage pools and Synology units with a flashing blue power light.

Stale drives and silent corruption

When a degraded array continues running with an unnoticed failed drive, the parity on the remaining drives slowly drifts out of date. If the failed drive then comes back partially online during a maintenance event, stale data can be folded back into the volume, corrupting the file system in ways that survive a rebuild. These cases require careful drive-by-drive timeline analysis to determine which sectors are authoritative.

Ransomware-encrypted array data

When ransomware reaches an array, the underlying RAID is usually intact — the encryption sits in the file system, not in the RAID metadata. Depending on the variant and the time window before encryption completed, recovery options range from partial file salvage to restoration from on-array snapshots or backup repositories like Veeam. Ransomware recovery details → · Veeam backup recovery →

RAID Levels We Recover

Gillware recovers data from every RAID level in common deployment, plus nested and proprietary variants:

• RAID 0 — striped, no redundancy. Failure of any drive takes the entire array down. Often used for scratch space or performance-critical applications without backup.
• RAID 1 — mirrored pairs. Surviving drive usually holds a complete copy of the data; the challenge is identifying which mirror is current after a failure.
• RAID 5 — striped with distributed parity. The most common configuration we recover, and the one most prone to failed-rebuild scenarios.
• RAID 6 — striped with dual parity. Tolerates two simultaneous drive failures; recoveries become difficult once a third drive degrades.
• RAID 10 — mirrored pairs, striped together. Resilient until both drives in a single mirror pair fail; then the entire array typically goes offline.
• RAID 50 and RAID 60 — nested configurations combining striping and parity, common in larger SAN deployments.
• JBOD and spanned volumes — not strictly RAID, but failures look similar and require the same reconstruction work.
• Proprietary layouts — Synology SHR, Drobo BeyondRAID, Netgear X-RAID, ZFS RAID-Z, Storage Spaces parity. Each has its own reconstruction path.

Platforms and Hardware

Server arrays

Locally-attached storage on rack and tower servers, typically running RAID 1, 5, 6, or 10 behind a Dell PERC, HPE Smart Array, LSI/Broadcom MegaRAID, or Adaptec controller. Common failures include controller hardware faults, battery-backed cache loss after a long outage, and motherboard or backplane events that propagate to the array. Server data recovery → · Dell server recovery · HP/HPE server recovery

RAID controllers

Dedicated recovery guidance by controller brand for the failure modes that disproportionately end up at our lab. Each page covers the controller’s history, model lineup, documented error conditions, and the specific commands or prompts that destroy data.

Dell PERC. The dominant RAID controller across the PowerEdge fleet, built on Broadcom MegaRAID silicon. Foreign Configuration import after a controller swap, preserved cache flushed against the wrong members, and failed rebuilds on the H730 / H740P generation are the most common Dell PERC conditions we recover.

HPE Smart Array. HPE’s in-house RAID line on ProLiant servers, with a proprietary metadata format distinct from SNIA DDF. The 1719 controller lockup on P440ar, the 1716 / 1915 unrecoverable-media-error advisory, and the a00053311 firmware-induced brick scenario on 4 GB cache configurations are the failure modes that drive Smart Array cases to us.

LSI / Broadcom MegaRAID. The OEM silicon underneath Dell PERC, IBM and Lenovo ServeRAID, Intel RAID, and direct deployments in Supermicro and white-box servers. StorCLI foreign-config events, drives forced from Unconfigured Bad back online, CacheCade orphan data, and Tri-Mode NVMe complications on the 9460 / 9560 / 9670 generation define the active MegaRAID caseload.

Adaptec / Microchip SmartRAID. Three architectural generations (Series 5/6/7, Series 8, SmartRAID 3xxx) with no array-import path between them — Microchip’s own documented position. The most common Adaptec case is a cross-generation controller upgrade that left every array unrecognized on the new card, with drives appearing as Ready instead of Foreign.

IBM and Lenovo ServeRAID. MegaRAID silicon throughout the active fleet — from the IBM-era M5014 / M5015 / M5110 / M5210 to the current Lenovo ThinkSystem 930 / 940 / 9350 generations. VPD mismatch on controller swap, foreign-config import dialogs in XCC, and the HT504819 advisory (firmware breaks VMware ESXi access) are the recurring ServeRAID cases.

Intel RAID. Two distinct product lines that share a brand: the LSI-rebadged RS3 and RMS3 hardware cards (officially end-of-life as of February 2024 with no further firmware updates), and the chipset-mediated RST / RSTe / VROC software RAID with its own IMSM metadata format. Both paths are recoverable, with the right diagnosis at intake.

3ware. The most aged-out controller line we cover — AMCC 2004, LSI 2009, brand retired around 2011. The 9650SE, 9690SA, and 9750 generations are now in their second decade of service with no firmware support and an attriting driver story; recovery is always off-controller from drive images because no current vendor’s hardware can read 3ware metadata.

NAS devices

Network-attached storage from Synology, QNAP, Netgear ReadyNAS, Buffalo TeraStation/LinkStation, Drobo, FreeNAS/TrueNAS, and SnapServer. NAS recoveries are often complicated by proprietary RAID layouts and embedded operating systems that need to be parsed before the volume can be reconstructed. NAS data recovery → · Synology · QNAP · Drobo · FreeNAS/TrueNAS

SAN systems

Storage area network failures — Dell EqualLogic and PowerVault, HPE MSA and 3PAR StoreServ, IBM Storwize, NetApp, and others. SAN recoveries usually start with a single drive failure that cascades into an unmountable volume after a controller event. SAN data recovery →

Virtualized infrastructure

VMware vSphere/ESXi datastores, Microsoft Hyper-V volumes, and Citrix XenServer storage repositories. When the underlying RAID fails, the virtual machines living on it are not directly damaged — but they’re inaccessible until the volume is reconstructed and the VMDK/VHDX files are extracted. VMware/ESXi recovery · Hyper-V recovery · XenServer recovery

How a RAID Recovery Works at Gillware

1. Submit the case. Tell us what failed, what symptoms you’re seeing, and what’s on the array. We send a prepaid shipping label and ship-safe packaging guidance.
2. Receive and inventory. Every drive is logged by bay position, model, firmware revision, and SMART state on arrival. Drives are never operated in the original array during this phase.
3. Cleanroom imaging. Each drive is imaged on isolated, write-blocked hardware in our ISO 5 cleanroom. Physically damaged drives are repaired with donor parts as needed before imaging.
4. RAID parameter reconstruction. Our engineers reverse-engineer the array’s stripe size, drive order, parity rotation, and offset from the on-disk metadata. We do not require the original controller or its configuration backup.
5. Logical reconstruction. Our in-house RAID recovery software (HOMBRE) assembles the virtual array from the imaged drives. From there, file system recovery proceeds on the assembled volume.
6. Data return. Recovered data is returned on new media (or transferred securely, depending on size and sensitivity). We do not return data on the original failed drives.

Why Gillware

ISO 5 Class 100 cleanroom. Drives with physical failures — head crashes, motor problems, scratched platters — can only be safely opened in a certified cleanroom. Ours is ISO 5 Class 100, the same class used in sensitive electronics manufacturing.

SOC 2 Type II audited facility. If your array holds regulated data — PHI, PCI, financial records, attorney-client material — the audited controls around our handling of it matter. Chain-of-custody documentation is available on request.

Proprietary RAID software. Our in-house RAID reconstruction software (HOMBRE) handles arrays that off-the-shelf tools won’t. Many of the cases we accept have been declined by other labs because their tooling didn’t recognize the on-disk layout.

More than two decades of recoveries. Gillware has recovered data from over 100,000 storage devices since 2004 — spanning every major RAID controller manufacturer, every common NAS and SAN platform, and a long list of vendors that have since exited the market.

Trusted by Dell, VMware, and 2,000+ MSPs. Gillware is the only data recovery company listed on Dell’s website. VMware refers customers to us for virtual-infrastructure recoveries. More than 2,000 managed service providers and computer repair shops refer their clients to us when they need data recovered.

U.S.-based engineers. All recovery work happens at our headquarters at 1802 Wright Street in Madison, Wisconsin. Your drives do not leave the country.

Pricing and Engagement

The evaluation is always free. After our engineers diagnose the failure and confirm what recovery is possible, you receive a firm written quote — not a range, not an estimate that grows as the work progresses — before any recovery work begins. You decide whether to proceed.

For single-drive recoveries our standard “no data, no charge” engagement applies: if the recovery is unsuccessful, you don’t pay for the work. Multi-drive RAID, NAS, SAN, and server cases are more complex and may carry an engineering deposit to cover the engineer hours required for parameter reconstruction and donor-drive work, regardless of the final outcome. The deposit and the full price are disclosed in the quote before you authorize the work. More on data recovery pricing →

Start Your RAID Recovery

If your array is down and the data on it matters to your business, the next step is to power it off and start a free evaluation. We’ll image the drives, reconstruct the array, and quote you a firm price before any recovery work begins.

Start a free RAID recovery evaluation →

Prefer to talk to someone first? Call 1-877-624-7206 during business hours (M–F 8 am–7 pm, Sat 10 am–3 pm Central), or schedule a 15-minute consultation with a client advisor. For business-critical downtime, ask about emergency data recovery service.