Open, and the first look is free · 9am–5:30pm, Mon to Fri Quicker to ring: 0800 6890668
RDR Reading Data Recovery 0800 6890668 Get it quoted
RDR / What we take in / Servers and their RAID sets

Servers · RAID sets that have stopped

Server data recovery in Reading. The server has stopped; the disks inside it are very probably fine.

In virtually every server job that reaches the Oxford intake lab, the disks themselves are healthy. The failure lies with the equipment around them: a controller whose idea of the set no longer matches the disks actually in the bays, a console prompt whose two buttons are both expensive, and a write cache still holding data the mains cut short. Every member is copied before any repair is attempted, and the repair work happens on those copies, so your controller can stay bolted in the chassis. The entire volume comes back: mail stores, file shares, virtual machines, databases and all. From £500 + VAT, one figure in writing after a free diagnosis. A distributor at Theale and a research spin-out on the science park at Shinfield send in the disks from the same chassis.

Only pay if we recover your data, on most jobs The diagnosis is free; then one fixed figure in writing Parcels arrive from Newbury, Woodley and Theale

An engineer answers, and looking is free
0800 6890668

Match the server symptom to the fault.

Different fault? Begin at the triage →
What you are seeingWhat is likely wrongWhat happens next
On the PERC: Foreign Configuration DetectedWhat the members say about the set and what the card knows have stopped matching, so it stops rather than guess. At this point nothing is lostGive the console no answer
HP: 1786 — Drive Array Recovery NeededA rebuild was started, and may be incompletePower it off. Copies before anything else
Amber bay lights after a mains failureWrites were cut off mid-write, so what the cache still held is unknown. The array's own description is intactDo not switch it back on
It boots, but there is no data volumeThe configuration on the card, or the file system above it; either way the sectors below are intactNormally comes back
The RAID controller itself has failedEach member records the bay order, the stripe size and how parity rotatesNo identical controller needed
Files have been copied off, but no virtual machine or database will runA copy that exists is not necessarily coherent, and only a coherent copy will startThat turns into a database recovery job
Packing and posting: get a quote first, by phone or with the form. Please make sure everything is packaged well enough to prevent it moving in transit, and put a value on the parcel that reflects the data, not the cost of the actual hardware. Post it tracked and insured to the Oxford intake lab, or drop it off there Monday to Friday, 9am to 5:30pm, no appointment needed. The return postage is covered by us. If you would prefer an engineer to talk you through the packing before you tape the box shut, please call ahead. All of this is set out on the packing and postage page.

The members carry the map of the server's array.

MegaRAID and PERC cardsDDF is an open standard, and both cards record it in the last sectors of each member. The images readily give it up, so the set can be rebuilt with your controller still installed in the server.
HP's Smart Array controllersHP's approach is different: RIS structures at the start of every member, and a parity block one stripe away from where most tools look for it. Point a default preset at that and you build a volume the server never had.
The prompt where both answers cost youAnswer this one at your peril. Import can lay stale metadata over stripes that were perfectly sound, and Clear deletes the description off every disk with nothing kept back to restore it. Take the images first and this prompt loses all power to hurt you.
Writes still sitting in the cacheThe moment battery-backed memory has the write, the write is reported as done, well ahead of when a platter actually sees it. If mains power goes out part-way through a flush, what breaks is the file system itself, invisibly and without any message on screen. That alone is reason enough to image before doing anything else.

From your parcel to your files coming back.

01

Logged the day it lands, and the look costs nothing Free

A case number is assigned to your device when we receive it. An engineer then finds the real fault (free) before anything else occurs; you will be advised clearly of what will be returned and what will not, along with a single written price. Charges cannot begin until you have read this and accepted.

The look costs you nothingA fixed price, in writingStill nothing to pay
02

Leave the machine exactly as you found it

First, turn the server off. Next, the drives come out one at a time, and each gets a label with its bay number before it goes anywhere. Do not answer anything the console asks you. Here, every member goes onto dedicated imaging hardware and is copied on its own (even those already rejected by the card), and no files are opened until all copies are complete.

Each disk imaged one by oneThe rejected members too
03

Reconstruct the array in software

The images contain the DDF or RIS records. Pull them out and you have all the geometry: stripe size, RAID level, which member sat in which bay and, on a parity set, which way the parity rotates. That is enough to assemble the array in software, and once that is done, nobody needs to worry that the card has failed.

Geometry read off the membersYour controller stays in the machine
04

A copy is not yet a working volume.

Whatever the array was carrying (NTFS, ReFS, ext4, XFS, a VMFS datastore) is repaired on the reassembled copy and never on the drives you sent us. It is then tested thoroughly: guests booted, shares mounted, databases attached, and individual files opened and read.

Repairs only ever on copiesChecked by mounting and booting
05

The list first, then the bill, then the files

You look at the file list first and make a decision about what to do. We will never invoice anything until you have said yes, and in most cases you only pay if we recover your data. All of the information that we recover will be put on new media purchased by us specifically for this job, and our company pays the cost of postage back to you. The case stays open on the bench until you tell us the files open on your own machine.

Nothing billed until you say yesNew media, bought for the jobPostage home is on us

What goes wrong most often

  • No two makes place the map in the exact same location: on an HP member RIS sits at the beginning of the disk, but DDF (which PERC and MegaRAID write) is placed right at the back, in the final sectors of the disk. Look at the wrong end and everything you calculate is just a guess.
  • The disk a card discarded still counts: a member thrown out weeks ago could hold the only readable copy of certain areas, which is why each image is compared against the others byte by byte. Nothing in this process is accepted on faith.
  • Default presets get Smart Array wrong: HP puts its parity block a stripe away from where most tools expect it, so the volume those tools give you is different from what your server actually had. It has to be assembled to HP's own scheme.
  • The cache battery is an early question: whether any write held in write-back made it to disk decides what state the file system is in, and we answer it before anybody is given an expectation to hold.

What each button really does: Import takes the foreign description as the true one and writes it over whatever configuration the card currently holds. Clear removes that description from every member, and once cleared nothing remains to restore it from. Both are available with a single keystroke and give absolutely no warning before they act. However, as long as you have complete copies, neither Import nor Clear can take a file from you. Imaging is not one stage among several on a job like this; everything else rests on it.

How one of these actually went.

RG · RDG-2026-1966ON FILE ✓

A flat cache battery, and a practice database that opened whole

A power outage that lasted a long time drained the cache battery completely. Once the power came back, the controller asked the practice a question that no one on the staff could safely answer, so it went unanswered. None of the member disks was touched; each was cloned first and the array's metadata was pulled from those clones. That gave the parity order, the array was rebuilt over the cloned copies, and the practice database opened whole, including the final write the cache had been holding.

The live database opened whole5 days from arrival to return

What helps, and what makes it worse.

First things to do

  • Photograph every screen the card puts up
  • Number each disk by the bay it was removed from
  • Send every disk, including those that appear finished
  • Say what it was running: SQL, Exchange, guests, shares

What makes it worse

  • Answering Import or Clear at that prompt
  • Fitting a new disk and starting a rebuild
  • Updating the card's firmware at this point
  • Powering the server up before copies exist

Answers before you commit to anything.

Our server will not start. Have we lost the lot?

Rarely. In most cases the disks are sound and the failure sits at the level above them: the controller's record of the set, the metadata written to each member, or damage to the file system. As long as you keep the power off and give the console no answers, you will still be in that same good position when the drives reach a bench.

'Foreign Configuration Detected' — what does that really mean?

It means the metadata written on each member no longer describes the array the controller expects to find. If you change the card, reseat a member in the wrong bay, or let a failing controller carry on, you will get this prompt. Stopping at this point shows the card is acting as intended, not that it is faulty. Import and Clear both write directly to your disks, so take images before using either. With images on hand, neither answer can cost you a file.

Do you need the RAID controller as well as the disks?

No. Each member holds its own account of the array. PERC and MegaRAID use a published format called DDF; HP uses RIS structures of its own. Either way, they are read straight out of the images and the set goes back together in software, so your card stays in the machine, and the server can be rebuilt around it afterwards.

Will our databases and virtual machines run again afterwards?

Usually, though generally speaking it will be two pieces of work as opposed to one. First, the reassembled volume has to give up the VMDK (or the MDF) in one piece. Next, a hypervisor has to be persuaded to recognise and mount the one, or SQL Server to attach the other. The second half of the process is covered by the database recovery page on this site.

If this sounds like yours, start here.

When a RAID 5 rebuild goes wrong → RAID 1 mirrors → Fujitsu laptops → Every device we handle →

Nothing gets worse while it sits switched off.

There is no charge for the look. You then receive a list of the files that opened, those that did not, and a fixed amount to complete the job. Keep it switched off until you have received that in writing.

0800 6890668

Get it looked at Posting it to Oxford