Server systems · array recovery
What fails in a server is rarely the storage itself. It is the apparatus around the disks: a RAID card at odds with the metadata it wrote, a boot-time prompt whose two answers are both destructive, a write cache emptied by a power cut before it reached the platters. Servers travel in from Maidenhead as bare disks; every step here is taken on images, no original card is required, and what returns is your volumes, your databases and your virtual machines.
Describe the fault to an engineer
0800 6890668
| The symptom | The likely cause | Start here |
|---|---|---|
| The PERC reports Foreign Configuration Detected | The record on the disks and the record in the card no longer agree, so it stopped deliberately; nothing has been lost | Answer neither prompt |
| 1786 — Drive Array Recovery Needed (HP) | A rebuild is queued, or failed before finishing | Power down; image before anything |
| Amber drive lights following a power failure | Writes cut short and a cache whose contents nobody can vouch for, though the array map remains on the disks | Force nothing back online |
| The machine boots and the data volume is missing | Controller state or the file system is at fault; the data below both of them is unharmed | Recoverable as a rule |
| The controller has failed | Order, stripe size and parity rotation all sit on the members | No matching card needed |
| The files are back, yet no guest or database will open | Being recovered and being consistent are different states; only the second is useful | See the VMware and database pages |
Nothing becomes chargeable until you have said yes to it. Each item takes a case number of its own the moment it arrives, an engineer establishes what has actually failed, and you are given a candid view of which files stand a realistic chance of returning. The single quote that follows is fixed, written down, and costs nothing.
Power the machine down, write the bay number onto each disk as it comes out, and answer nothing that appears on screen. Each member is then imaged separately on hardware built for the job, including any the card had rejected, before anything is read as data.
Those images carry the DDF or RIS records, which state the RAID level, the stripe width, the order the members sat in and, for RAID 5 and 6, the direction parity turns. With that settled the array is reassembled in software, and a dead card ceases to matter.
Whichever file system was riding on the array is repaired on the reassembled copy, whether that is NTFS or ReFS, a VMFS datastore, XFS or ext4. Then comes the test that counts: guests power on, databases attach, shares open.
Nothing is billed until you have seen the recovered file list in full and told us to go ahead. What comes back arrives on new media, with the return journey at our cost, and the case stays open at this end until you have opened every file yourself.
What the screen is actually offering: Import replaces the card's working configuration with whatever the foreign metadata asserts; Clear deletes that map from every disk, permanently. A single key selects either, and nothing reverses either — though once the images exist, neither can take anything from you. Cloning first is not a precaution. It is the method.
A UPS that ran down before the mains returned left the Smart Array asking questions nobody in the practice was willing to answer, and rightly so. Every member was copied first, the RIS metadata read off and the delayed parity accounted for, so the rebuild ran on images alone. The practice-management database opened whole, current to the cache's last committed write.
Seldom. What has broken is normally the controller's state, the array metadata, or a file system that has taken damage, while the disks are sound. Switch it off, answer no prompts, and the position stays in your favour.
That the metadata written on those disks contradicts the card's own record, which happens readily after a board swap, a drive put back in the wrong bay, or a controller beginning to fail. Halting is deliberate. Both answers on that screen can destroy data; clone the disks first and neither can.
No. Every member carries the layout with it: DDF metadata, an open standard, from PERC and MegaRAID, and RIS blocks of HP's own devising. Since reassembly runs against bench images, no identical card has to exist.
Both, and the distinction is worth drawing. Pulling a VMDK or an MDF back off the array is one job; getting the hypervisor to mount it, or the database engine to attach it, is a separate one. That second layer is covered on our VMware and database pages.
Each further power-up asks more of a drive that has already begun to fail. Open the case first and let the free diagnosis tell you what is left.