Lab accepting new cases ·  Mon–Fri, 9am–5:30pm Urgent? Call 01273 964902
BDR Brighton Data Recovery 01273 964902 Start a case
BDR / What we recover / RAID arrays & servers

Devices · RAID arrays & servers

Redundancy buys time. It doesn’t buy immortality.

Most RAID disasters aren't the first drive failing — they're what happens next: the rebuild that stresses a second marginal drive to death, the forced-online gamble, the wrong disk pulled. We work only on images, so the array can't get worse in our hands.

No fix, no fee on most jobs Free diagnosis & written quote Post-in from anywhere in Sussex

Talk it through with an engineer
01273 964902

If you're seeing this, you're in the right place.

Not listed? Run the triage →
Getting it to us: post your device tracked and fully insured to our secure intake lab — free return postage — or start by phone and we'll walk you through packing it. Sending details are on the contact page.

The makes and models on this bench.

Dell PERCPowerEdge RAID controllers — rebadged Broadcom/LSI, geometry stored on the drives in DDF metadata.
HPE Smart ArrayProLiant P-series — proprietary RIS metadata and delayed parity; arrays only import on HP controllers.
Broadcom / LSI & AdaptecMegaRAID and Microchip cards across Supermicro and white-box servers.
Software RAIDmdadm, Windows Storage Spaces — no card at all, all the same failure maths.

The exact message on your screen.

Seeing something else? →
The messageWhat it meansFirst move
Foreign Configuration Found (Dell PERC)The controller sees array metadata that doesn't match its memoryNeither Import nor Clear — image
1786 — Drive Array Recovery Needed (HP)A rebuild is needed or was interrupted; redundancy is compromisedStop-and-image event
1784 — Drive Array Drive Failure (HP)A physical member has failedDon't hot-swap and pray
1787 — Drives Improperly Attached (HP)Drives detected in the wrong baysOrder matters — stop
Virtual Drive is Degraded / OfflineRunning without redundancy, or not running at allPower down the array
1720 — SMART drive detects imminent failure (HP)A member is pre-failing inside a live arrayPlan the imaging now

How we recover it, stage by stage.

See recent recoveries →
01

Booked in, diagnosed free Free

Your device is logged with its own case reference the moment it arrives. An engineer assesses the fault, confirms what's actually recoverable, and you get a fixed price in writing — no diagnosis fee, no obligation, and no paid work until you say go.

Free diagnosisFixed written quoteNo obligation
02

Image every member

Each drive — including the 'failed' ones — is imaged individually on hardware tools. All work happens on copies; your original disks are never written to.

Every member imagedFailed drives included
03

Reconstruct virtually

Drive order, block size and parity rotation are worked out from the data itself, and the array is reassembled in software across the images — no controller required, no rebuild risked.

Order and parity derivedNo controller required
04

Recover the volume on top

File systems, virtual machines and databases are repaired on the reconstruction, and verified against a listing before anything is signed off.

VMs and databases mountedChecked before sign-off
05

Verified, returned, signed off

Before you pay the recovery fee you approve a full listing of what came back. Your data returns on new media with free return postage, and the case only closes once you've confirmed everything opens on your side.

File listing approvalNew media includedFree return postage

What the lab checks first

  • The Import / Clear prompt is a trap — importing a stale drive injects outdated metadata into live stripes; clearing erases the map entirely. Both are one keystroke, neither is reversible, and neither should happen before every member is imaged.
  • HP does it differently on purpose: Reserved Information Sectors on each drive and parity offset by one stripe (delayed parity) — which is why an HP array dropped into recovery software configured for 'standard RAID 5' reads as garbage.
  • The array's geometry lives on the drives, not the card — a dead controller almost never means lost data. Order, block size and parity rotation are all recoverable from the disks themselves.
  • The second failure is the story — rebuilds read every sector of every survivor, which is precisely how marginal drives get finished off mid-rebuild.

The real number behind the RAID 5 warnings: consumer SATA drives are specified at roughly one unrecoverable read error per 1014 bits — about every 12.5TB read. A big RAID 5 rebuild reads more than that from its survivors, which is why single-parity arrays fail their own rebuilds. It's a datasheet figure, not folklore — though how doomed that makes RAID 5 is still argued.

From the casebook.

EX · BDR-2026-0748VERIFIED ✓

A factory's RAID 5 with two dead members, recovered over a weekend

Production data trapped on a server that had eaten its second drive mid-rebuild on a Friday. All four disks imaged, the stripe reconstructed from three-and-a-bit good images, and the factory reopened on Monday morning.

100% critical data1 weekend

Before it reaches us.

Do

  • Power the array down and leave it down
  • Label every drive with its bay position before removal
  • Send all drives, including the ones marked failed
  • Tell us the RAID level and controller if known

Don't

  • Start or resume a rebuild on a degraded array
  • Force failed drives back online
  • Reinitialise or 'repair' the array in the controller BIOS
  • Let anyone run recovery software across the live array

Asked on this bench, answered honestly.

The controller marked a drive failed — do you still need it?

Yes, send every member. 'Failed' drives often hold the freshest copy of some regions, and reconstruction chooses the healthiest source for each block across all of them.

We don't know the original drive order any more. Fatal?

No — the correct order, block size and parity rotation are recoverable from the data patterns on the disks themselves. It's routine analysis, not guesswork.

Can you recover the virtual machines, not just files?

Yes. Once the array is rebuilt we recover VMDK, VHDX and database stores as first-class targets and verify they mount, not just that they exist.

How fast can a business-down array be turned around?

Multi-drive jobs typically run four to seven working days; genuine business-down emergencies can be worked continuously — say so when you call and we'll plan the intake around it.

Whatever's failed, don't power it on again.

Every restart of a damaged device costs data. Open a case first — the diagnosis is free either way.

01273 964902