BHDR / Specialist work / Dell PowerEdge recovery

Specialist · Dell PowerEdge recovery

Dell PowerEdge recovery in Birmingham. What the card lost is the record of how the disks fit together.

PowerEdge servers reach us from all over Birmingham: professional offices around Colmore, engineering units out in the Black Country, and small firms with one box in a cupboard that runs everything. The story rarely changes. An amber light nobody chased, a second drive gone some weeks later, then a controller announcing a foreign configuration it will not take back. By then the disks are seldom the real trouble. What has gone missing is the record of how they were arranged.

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

Reading the PowerEdge symptoms, one by one.

No match here? Run the triage →

What you see	What is behind it	What to do
Foreign configuration found at POST	The card has lost the array and is reading the disks' own metadata	Do not clear it; ring us
No boot device on restart	The virtual disk is offline: two members have dropped out of the set	Stop there; do not initialise
A drive pulled from the wrong bay	Redundancy went the moment it came out, though the disks are unharmed	Usually recoverable
One member flagged as predictive failure	That disk is going now, and a rebuild would read every sector of it	Image it while it still reads
The controller offers Import or Clear	Clear throws away the only account of how the stripes were laid down	Photograph the screen and ring
A rebuild that halted part of the way	A second member cannot return the regions that the rebuild wants	Cut the power before it retries

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.

What a PowerEdge holds, and what undoes it.

PERC controllersA PERC card takes a handful of SAS or SATA disks and hands the operating system one virtual disk. How the blocks are spread over the members lives in the card's own memory and in DDF metadata written to every disk in the set.

R-series and T-seriesRack machines a couple of units high, and towers that stand under a desk. Both hold their disks in hot-swap carriers on a SAS backplane, and both will let a disk be drawn out while the thing is running. Out of the carriers they are ordinary drives on a bench.

The first amber lightWhere most of these jobs actually begin. One member drops out, the set carries on without redundancy, and the light gets noticed weeks later.

Cache, battery and consistencyThree limits worth knowing before you start. A consistency check writes to the set; it is not a diagnosis. A flat cache battery drops the card into write-through, and a power cut with dirty cache still held can strand the last writes. And Clear takes the array record off every disk at once.

From arrival to the files going home.

Recent jobs on record →

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

Bays logged, then the disks out

Nothing is powered up first. Each carrier is photographed where it sits, the slot number written on the disk itself, and the set comes out together, with the controller model and the RAID level noted against it.

Bay order photographed firstThe exact fault pinned down

Every disk imaged in turn

Every disk is copied on a channel of its own before a single question is asked about the array. The ones with weak zones are read in short passes, their difficult regions left until last, and no original is written to at any point.

Every member copiedNo original ever written to

Rebuild the virtual disk

Stripe size, the order the members sat in and the direction parity turns are read out of the images themselves, not taken from the card. The set is assembled read-only from those copies, and the file system opened above it.

Stripe order worked outReadable files, not stripes

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 or Clear decides the job — Import tells the card to trust the record the disks carry; Clear scrubs it off them. A cleared set is usually recoverable from images, but only while nothing has been written since.
Bay order is part of the data — a set can be put back from images with no controller involved, but only if we know which slot each disk sat in. Write it on the carrier before anything leaves the chassis; an unlabelled six-drive set costs a day of working it out.
A rebuild is the dangerous hour — it reads every sector of every surviving member, and it does that on disks that have already been carrying the set on their own. A hot spare will start one for you, unasked, in the middle of the night.
iDRAC keeps the timeline — the lifecycle log holds which slot dropped, at what hour, and whether a rebuild ran afterwards. That order decides what gets imaged first. Export it if you can; if not, leave the machine alone and we will read it here.

Why a PowerEdge turns up holding the only copy: it is the thing everything else backs up to. Shares, mailboxes, the accounts package, the drawing archive, the cameras pointed at the yard — all of it lands on one set of disks, and because that set has redundancy, redundancy gets treated as the backup. Two stories account for most of what arrives. The slow one: a member drops, the amber light is noted and left, and weeks later a second goes. The fast one: a power event, or a card swapped for a spare, and a foreign configuration nobody knew how to answer. The slow one costs a rebuild; the fast one often costs nothing at all, provided the writing stopped. Tell us which you have and we will say where it sits.

Recent pages of the casebook.

BH · BHD-2026-8841RECORDED ✓

The foreign configuration that had already been cleared

A T340 tower in a Solihull office had lost one member of its four-drive set in the spring and nobody acted on it. When a second dropped out, an engineer on site cleared the foreign configuration to get the card past its prompt, then stopped and rang. That was the right instinct. Every disk was imaged, the stripe order was worked out from those images rather than the controller, and the file server came back whole. Three days from arrival.

100% imaged3 days from arrival

Before the parcel goes.

Do this first

Send every drive, each marked with its bay number
Tell us the RAID level and the controller model
Keep the chassis off the mains
Include the iDRAC log if you have it

What not to do

Clearing the foreign configuration to tidy it
Starting a rebuild to see if it takes
Reinitialising the virtual disk to get it back
Moving the disks around between bays

The questions that come up every week.

The PERC has found a foreign configuration. Do I import it?

Not before somebody has looked at the state the members are in. Import tells the card to trust the array record the disks are carrying and run with it, and on a set where every member is present and nothing has been swapped that is usually the right answer. Where a disk has already been replaced, or a rebuild has run since the fault, importing can set another rebuild going over the half that still reads. If the data matters and no backup exists, image the drives first and import afterwards.

Someone cleared the configuration already. Is the data gone?

Usually not. Clear takes the array record off the disks; it does not touch the blocks your files sit in, and those blocks are still lying in the order they were written. What ends a case is what tends to happen next — a fresh virtual disk built across the same drives, a background initialisation left running overnight, an operating system put on to see whether it comes up. Every one of those writes across the set. Pull the power now and the odds stay good; leave it running and they fall by the hour.

The rebuild stopped at forty per cent. What happens now?

A rebuild reads every sector of every remaining member, which is the heaviest thing you can ask of disks that have already been carrying the set short-handed. When one halts, it is normally because a second drive cannot return a region the rebuild needs. Stop it there. Send the whole set in, the drive that dropped out first included — that one is behind the others but often reads cleanly, and its copy of a stripe fills the gap the rebuild could not.

Do I post the whole server, or only the drives inside it?

The drives on their own, each marked with the bay it came out of. We need neither the chassis nor the card: the layout is worked out from the images, and bay order is the one thing an image cannot tell us. Wrap each disk separately, post the parcel fully insured and tracked to the lab in Manchester, and slip in a note giving the RAID level and the controller model if you know them. A NAS may travel whole; a 2U server may not.

Other pages worth a look here.

Drives inside → Ticking drives → No drive appears → Media we take in →

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

Start with a free diagnosis Post it to the lab

What we take in for recovery

Faults we see

Forensic and CCTV work

How it all works