Call us — 0191 406 1051
Mon–Fri · 9am–5:30pm · No fix, no fee
Start a free diagnostic →
// case file · RAID 5 · 4 disks · controller firmware

The RAID card forgot what it was holding.

A four-disk RAID 5 that the operating system stopped seeing entirely. The disks were fine. The array was fine. The controller was the thing that had failed — and that is a distinction worth understanding before you let it try to fix itself.

← All case files · from £500 + VAT

Device

4 × disk RAID 5, hardware controller

Failure

Controller firmware corruption

Complication

Two members with bad sectors

Outcome

Array rebuilt without the controller

// the brief

What arrived, and what was at stake.

A business RAID 5 array, four disks, holding financial records and project files. No backup. The operating system simply stopped recognising the volume — not degraded, not rebuilding, just absent.

The cause was firmware corruption on the RAID controller itself, which had left the card unable to communicate coherently with its own members.

// on the bench

What the diagnosis found.

01

The controller firmware was corrupted.

The card could no longer read its own configuration, so it presented no array at all.

02

Two of the four drives had bad sectors and firmware instability

of their own — not enough to have failed outright, but enough to make a controller-driven rebuild lethal.

03

The RAID metadata was partially lost

, so no automatic rebuild was ever going to succeed.

The controller is not the array.

This is the single most useful thing on this page. People believe the RAID card holds their data. It does not. The disks hold the data; the card holds the map. When the card corrupts, the data is still sitting on the platters exactly where it was — and the one action that will actually destroy it is letting a confused controller write a new map over the top.

A RAID 5 with two flaky members is one bad rebuild away from being a forensic job. That is not a hypothetical; it is the most common way we see arrays destroyed.

// the recovery

How it was done.

// outcome

What came back.

The array was reconstructed from the clones and the data returned. The controller was never repaired, because it never needed to be — it was not holding anything.

What determines the outcome on a job like this is not the controller at all. It is how completely the weakest member images. RAID 5 tolerates one missing disk by calculating it back from parity. Lose a second member's sectors in the same stripe and that stripe is gone for good, which is why the two unstable drives were the entire job and the corrupted card was a footnote.

// the transferable bit

What to take from this.

If your RAID controller starts behaving oddly, stop. Do not reseat drives to "see if it helps". Do not accept the prompt to initialise, import a foreign configuration, or rebuild. Do not update the controller firmware in the hope it clears.

Photograph the drive order first — which disk was in which bay — then power it down and label them. Disk order is one of the variables that has to be solved in the lab, and if you already know it, you have saved yourself real time and real money.

// read next

Related.

// your turn

Lost something that matters? Free diagnosis, a fixed price, and no fix, no fee.

Drop the drive at our Quayside reception, or post it to us — it costs nothing to find out what happened. You get a written figure from the fixed bands before any work begins.