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

The RAID card lost track of its own disks.

A four-disk RAID 5 that vanished from the operating system altogether. Nothing ailed the disks, and nothing ailed the array. It was the controller that had failed — a distinction well worth grasping before you trust it to sort itself out.

← All case files · from £500 + VAT

Device

4 × disk RAID 5, hardware controller

Failure

Corrupted controller firmware

Complication

Two disks with bad sectors

Outcome

Array rebuilt, controller bypassed

// the brief

What arrived, and what was at stake.

Four disks, a single business RAID 5, financial records plus a heap of project files, and no backup at all. The operating system had suddenly stopped seeing the volume — not degraded, not rebuilding, just gone.

The culprit was the RAID controller: corrupted firmware had left the card unable to talk properly to its own disks.

// on the bench

What the diagnosis found.

The array does not live in the controller.

01

The controller’s firmware had corrupted

so it couldn’t read its own configuration and offered up nothing.

02

Two of the four disks were themselves unstable

carrying bad sectors and firmware oddities — not dead, but plenty to make a controller-led rebuild fatal.

03

Part of the RAID metadata had gone

which ruled out any automatic rebuild.

This is the one sentence here worth committing to memory. Everyone supposes the data sits on the RAID card. It doesn’t: the data lives on the disks, while the card merely stores the map. Corrupt the card and your data is still precisely where it always was on the platters — and the surest way to lose it is to let a baffled controller stamp a fresh map over the top.

Hand a RAID 5 two unsteady members and it’s a single failed rebuild from a forensic recovery. Not as a theory — it’s the way we most commonly see these arrays wrecked.

// the recovery

How it was done.

The controller we simply set aside — nothing on it was worth saving — and did the whole job from the disks. All four were cloned read-only behind a write-blocker, the two shaky members read on a DeepSpar to recover as many good sectors as they’d give without tipping them over. From the clones we reconstructed the array’s own geometry (block size, disk order, the way parity rotated) — the very map the dead card could no longer supply — and brought the volume back up in software. The controller we never touched, because it was never what was wrong.

// outcome

What came back.

The array was rebuilt off the clones and the data returned. We never fixed the controller, for the plain reason that there was nothing on it to fix.

The controller had no bearing on how this finished. What counted was how completely the weakest disk would image. RAID 5 covers one missing disk by computing it back from parity; lose a second disk’s sectors inside the same stripe and that stripe is lost for good, and that is exactly why the two unstable drives were the entire job, and the dead card barely a footnote.

// the transferable bit

What to take from this.

The second a RAID controller starts playing up, stop touching it. Don’t pull and reseat disks “just to check”. Don’t consent to initialise, to import a foreign config, or to rebuild. Don’t flash its firmware hoping the fault clears.

Photograph the disk order first — which drive sat in which bay — then power it down and label them. Disk order is one of the things we’d otherwise have to work out in the lab; give it to us already known and you’ve 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.

Bring the drive to our Guildford Business Park reception, or post it over — it costs nothing to learn what went wrong. You’ll have a written price from our fixed bands before any work starts.