An engineering firm’s HPE ProLiant server dropped four virtual machines offline at once. The RAID controller could see all eight disks, but the RAID 10 volume simply refused to mount — a corrupt partition structure sitting on top of a physically healthy array. The danger here isn’t the fault; it’s the ‘fix’. Let a controller rebuild or re-initialise in that state and you can overwrite the very data you’re trying to save. We imaged all eight disks, reconstructed the array read-only, and rebuilt the volume from the copies.
An engineering company ran four separate business systems — each a virtual machine — on a single HPE ProLiant server backed by a RAID 10 array of eight 1 TB SAS disks. One morning all four VMs went offline together. The server powered up, the RAID controller enumerated every disk as present and healthy, but the RAID 10 logical volume would not mount, and with it the four VMs holding CAD files, project data, financial records and operational systems became inaccessible. Crucially, nobody let the controller start a rebuild or re-initialise the array to ‘get it back’ — the machine was powered down and the whole set of disks brought to us, which is what made a clean recovery possible.
RAID 10 is a stripe of mirrors. The eight disks are first paired into four mirrored sets (RAID 1), and data is then striped across those four pairs (RAID 0). Every block therefore exists on two disks, and reads and writes are spread across the array for speed. It’s a resilient layout — you can lose one disk from each mirror and keep running — but reassembling it after a logical failure requires knowing three things precisely: the stripe (block) size, the order of the pairs in the stripe, and which two disks form each mirror. Get any of those wrong and the reconstructed data is scrambled. On this array the disks were fine; what had gone was the roadmap sitting above them.
A controller that reports all disks healthy but won’t present the volume is almost always describing a logical fault, not a hardware one. Here the partition table on the assembled array was corrupt. The partition table is the small structure that tells the operating system where each volume begins and ends and how it’s formatted; damage it and the OS can no longer find the file system, even though every byte of that file system is still sitting intact on the platters. A power event or an interrupted write during a controller operation is a common cause. Because the underlying RAID 10 members were mechanically sound and the mirrors still held matching data, the job was one of rebuilding structure — not chasing failing hardware.
The single most damaging thing you can do to a RAID array in this state is ask its own controller to repair it. A rebuild assumes it knows which disk is stale and copies over the top of a mirror — if it guesses wrong, or if the real fault is logical, it writes bad data across good. A re-initialise or ‘create new array’ prompt, which controllers sometimes offer when they can’t read a config, discards the metadata that describes the array entirely. Either can turn a recoverable volume into an unrecoverable one in minutes. So the controller was kept out of it: every disk was removed and handled individually, and the array was reassembled in software from images, where nothing we did could ever be written back to the originals.
Each of the eight SAS disks was cloned in full to healthy storage through a hardware imager with the sources write-blocked; all eight imaged cleanly, confirming the diagnosis of a logical rather than physical failure. Working entirely from those images, we then determined the RAID 10 geometry by analysis — examining the data patterns across the disks to establish the stripe size, the correct order of the mirrored pairs, and the pairing of each mirror, rather than trusting a possibly-damaged controller config. With the geometry confirmed we virtually assembled the array read-only, presenting the reconstructed RAID 10 volume exactly as the server would have seen it — but as an image we could analyse freely and never alter.
On the reconstructed volume the corrupt partition table was rebuilt, using the backup structures and the recognisable start of the file system to re-establish where the volume began and how it was formatted, which brought the host file system back to a readable state. From there the four virtual disk files (VMDK and VHD) were extracted and checked: where a VM’s own file system or disk descriptor had been left inconsistent by the abrupt shutdown, it was repaired inside the recovered image so the machine’s data was complete and mountable. Each of the four systems was validated so we could confirm the CAD projects, databases and business files inside them were whole before anything was handed back.
The recovered virtual machines and their contents were checked against the client’s expectations — project folders present, databases consistent, record counts as they should be — then delivered back on fresh media ready to be restored to a rebuilt host. We also flagged the obvious lesson: RAID is redundancy against a disk failing, not a backup against corruption, ransomware or human error, all of which hit every mirror at once. A separate backup of the VMs, ideally offline or offsite, is what turns an event like this from a six-day recovery into a routine restore.
Per-disk hardware imaging with write blockers (8× SAS) · RAID 10 geometry analysis (stripe size, disk order, mirror pairing) · software array reconstruction, read-only · partition-table rebuild · VMDK/VHD extraction and guest file-system repair. All work in-house at our Belfast lab.
Don’t let the controller rebuild or re-initialise — power it down and send us the disks for a free, no-obligation diagnostic. We’ll tell you what can be recovered and put a fixed price in writing before any work starts, and on most jobs it’s no fix, no fee. We recover RAID and virtual servers for businesses right across the UK.
Usually not. When every disk reports healthy but the volume won’t present, the fault is almost always logical — a corrupt partition table or array metadata — rather than a failed disk, and the data underneath is typically intact. The key is to stop there: don’t rebuild or re-initialise the array, because that’s what can overwrite the recoverable data. Power it down and get a diagnostic.
Not if the data matters. A rebuild copies one disk over its mirror on the assumption it knows which is current — if that assumption is wrong, or the real problem is logical, it writes bad data over good across the array. Reconstructing the array in software from images, the way we do, means the originals are never altered and there’s no gamble with your data.
Yes. We extract the VM disk files (VMDK, VHD and similar) from the rebuilt array and, where the abrupt failure left a guest file system or disk descriptor inconsistent, repair it inside the recovered image so each machine’s data is complete and mountable. We validate the VMs before returning them so you know what you’re getting back.