Taking in new cases now · 9am–5:30pm, weekdays In a rush? Ring 0800 6890668
BHDR Birmingham Data Recovery 0800 6890668 Get it seen
BHDR / Everything we recover / Servers, NAS & RAID

Devices · RAID arrays and servers

RAID and server recovery, Birmingham. The first disk goes in silence — that is the danger.

Arrays rarely die of the first fault. They die of what gets done next — a rebuild dragging an already tired disk through one unbroken read until it quits, a rejected member shoved back into the set, disks shuffled between bays to see if that helps. Mirroring buys you less than people think, because both halves went in on the same day and have spun the same hours since. Everything here is done on images, so nothing gets any worse once the disks reach us from Birmingham.

Nothing recovered, nothing to pay Diagnosed free, then one fixed price From Walsall, Dudley or Coventry, it travels by post

Tell an engineer what it is doing
0800 6890668

This lands on our bench most weeks — it is ordinary work.

No match here? Start the triage →
Sending it by post: send it tracked and fully insured to our intake lab, and we cover the postage coming back; if you want the packing checked before it goes, an engineer will talk it through with you. Every step is written out on the posting page.

The RAID and server brands we see most often.

Dell PERCThe card in most PowerEdge boxes: LSI and Broadcom hardware under a Dell name, writing DDF metadata to every disk.
HPE Smart ArrayP-series cards inside ProLiant servers, with RIS metadata and delayed parity that nothing beyond HP's own tools understands.
Broadcom / LSI & AdaptecMegaRAID and Microchip controllers, standard in Supermicro chassis and in servers assembled on site.
Arrays with no cardLinux mdadm and Windows Storage Spaces: nothing to fail in hardware, and the same sums to do when a disk goes.

What those messages mean.

Fault not here? →
What you seeWhat is behind itWhat to do
Foreign Configuration Found (Dell PERC)What the disks say disagrees with what the card remembersChoose neither; image the set first
1786 — Drive Array Recovery Needed (HP)Redundancy has gone, and a rebuild is pending or part donePower it off and image it
1784 — Drive Array Drive Failure (HP)One disk in the set has goneDo not drop in a spare and hope
1788 — Drives Improperly Attached (HP)Somebody has reseated the disks out of orderOrder is everything here; stop now
Virtual Drive is Degraded / OfflineThe volume has lost redundancy, or has vanished outrightShut the whole lot down
1720 — SMART drive detects imminent failure (HP)A disk still in service is announcing its own failureCopy it the same day

From arrival to the files going home.

Recent jobs on record →
01

Case opened, and the diagnosis costs nothing Free

Every item gets a case number of its own the day it lands. An engineer then works out what has actually failed and tells you plainly which files have a real chance of coming back and which do not. Only then does a price follow: one figure, fixed, in writing, and it costs you nothing to see it. Nothing is charged until you say yes.

The diagnosis is freeOne price, put in writingNothing agreed
02

Image every disk first

Every disk goes onto purpose-built imaging kit — the ones the controller had already condemned as well. From then on the job runs entirely on those copies, and not one byte is ever written back to the disks that arrived from you.

Each disk imaged on its ownThe rejected ones as well
03

Reassembled in software

Stripe size, disk order and the rotation of parity all come out of the data's own layout. The set is then assembled over the images on our equipment. Your controller takes no part in any of it, and nothing at any point is asked to rebuild.

Disk order worked outNo controller required
04

Repair the layers above

Once the array stands, the file system is repaired, then the virtual-machine containers, then the databases, and the whole lot is checked against a full listing before it goes anywhere.

VMs and databases mountedVerified before it goes back
05

Approved by you, then posted back

No invoice is raised until the full list of recovered files has sat in front of you and you have said go ahead. Your data comes back on media we buy new, posted at our expense, and the job is not closed here until every file has opened on your own machine.

Your say-so on the file listYour data on new mediaWe cover the postage back

What the first look turns up

  • Import and Clear are equally dangerous — one copies an old member's view of the array over stripes that were perfectly intact; the other deletes the layout outright. Each is a single keystroke with nothing to undo it, and neither should be touched until every disk has been imaged.
  • HP built its arrays to its own pattern: Reserved Information Sectors on every disk, and parity placed a stripe later than the textbook arrangement — the term is delayed parity. Point an off-the-shelf RAID 5 tool at ProLiant members and what comes out is nonsense.
  • The layout lives on the disks, not in the card — which is why a dead controller frightens people far more than it should. Disk order, stripe size and the direction parity turns are all recoverable from the disks alone.
  • The damage comes with the second failure — rebuilding asks every remaining disk for one unbroken read from start to finish, and that is precisely what a borderline drive cannot deliver.

Where single parity got its bad name: the datasheet for a consumer SATA disk allows about one unrecoverable sector in every 1014 bits read — roughly one per 12.5TB. Put a large single-parity array through a rebuild and the survivors between them have to hand over a good deal more than that without a stumble, which is the point at which rebuilds fall over. The figure comes from the drive makers themselves rather than from us, though engineers still argue over how hard it bites in the real world.

Recent pages of the casebook.

BH · BHD-2026-8748RECORDED ✓

A second disk failed mid-rebuild; the line ran on Monday

The rebuild took a second member with it on the Friday, and the live production data went out of reach. Nothing was powered up again. All four disks were copied to our own storage, the stripe worked out from three clean images and what the fourth still held, and the plant started on time Monday.

100% of what mattered1 weekend

Before the parcel goes.

Do this first

  • Power the server down and leave it alone
  • Record the bay every disk came out of
  • Send every disk, including the dead ones
  • Say what RAID level and card it used, if known

What not to do

  • Kick off or resume a rebuild on an array already degraded
  • Reseat a disk the card has thrown out
  • Reach for repair or initialise in the card's setup menu
  • Point recovery software at the array while it is running

The questions that come up every week.

The controller has failed one of the disks. Do you want it anyway?

Yes — send every disk. The one the card threw out often carries the newest version of certain stripes, and each block is taken from whichever image gave it up most cleanly.

No one wrote down the bay order. Have we sunk the job?

You have not. Stripe size, disk sequence and the way parity moves can all be read out of the data itself. That is analysis we do daily, not guesswork.

Is it only files, or do the VMs come back too?

Both. With the array standing, the VMDK and VHDX files and the database stores are pulled off ahead of everything else, then each one is mounted here and opened, not simply ticked off a list.

We have stopped trading until this is back. How long will it take?

Four to seven working days is normal for a set of several disks. If trading has genuinely stopped, we will run the case without a break — tell us that on the phone and the intake is booked to suit your deadline.

Nothing more is lost while the power stays off.

Every extra power-up takes something off a drive that is already going. Leave it switched off and let the free diagnosis say what still reads.

0800 6890668