He is handling a customer's server — a Dell PowerEdge with SAS Seagate Cheetah disks, one for the OS and "2 SAS 146B Seagate Cheetah in RAID0 for the data (dont ask me why :) )". Now "One of disks of the raid pair has failed, the other one is shown as healthy", and he asks whether the data can be recovered. The reassuring word "healthy" on the surviving disk is the detail to handle carefully: in a RAID 0 pair, a healthy survivor is necessary but nowhere near sufficient, because it holds only half of every file and the recovery still depends entirely on imaging the one that failed.
| Media | Dell PowerEdge 2900 with SAS Seagate Cheetah 146GB disks — a separate OS disk and a two-disk RAID 0 data pair, one member of the pair failed, the other reporting healthy |
| Reported situation | Enterprise server with a striped data pair · one RAID 0 member failed, the other shown as healthy · recovery of the striped data required · presented by a trade contact on the end customer's behalf · price and feasibility both asked |
| Fault class | Single-member failure in a zero-redundancy SAS stripe — recovery of the whole data volume contingent on imaging the failed member, with the healthy survivor supplying only its interleaved half |
| Equipment used | Both SAS members imaged under hardware write-blockers with SAS-capable interfacing on the bench · failed member assessed on PC-3000 UDMA and recovered by its fault — clean-air donor work under laminar flow if mechanical · healthy member imaged directly as the stripe's other half · RAID 0 reassembled virtually from both images in UFS Explorer RAID, stripe geometry confirmed against the data · server volume and its filesystem extracted, hash-verified, delivered through the trade contact |
His parenthetical says it all: RAID 0 for important server data is a choice that prioritised speed over survival. Striping the data pair doubled throughput and removed all redundancy — no mirror, no parity. On a server that is a striking gamble, and it is the reason a single disk failure has taken the whole data volume down rather than degrading it gracefully as a mirrored or parity array would.
"Healthy" on the survivor is true and insufficient in the same breath. The surviving disk being healthy is genuinely good — it means one clean image comes for free. But in a stripe it holds only alternating pieces of every file, a complete copy of nothing. The recovery cannot proceed on the healthy disk alone; it needs the failed disk's contents to interleave back with it, which puts the entire job's weight on imaging the member that died.
The failed disk's condition is the whole prognosis. A Cheetah is an enterprise SAS drive, robust but not immune, and its specific fault — electronic, firmware, or the mechanical failure that commonly ends high-RPM server drives — determines everything. The reassembled volume can only be as complete as the failed member's image, so that image is the crux and is treated as such.
The OS disk is a useful bystander, not part of the puzzle. Running separately from the stripe, the operating-system disk is not needed to reconstruct the data pair. It may help confirm the array's configuration if its records survive, but the data volume is rebuilt from the two striped members alone.
Reassembly is virtual, verified, and never on the originals. Both members imaged, the stripe is rebuilt from the images with geometry read from the data and confirmed, and the server's filesystem and data extracted from the correctly assembled volume. On enterprise arrays especially, a wrong stripe parameter produces convincing but wrong results, so verification against the actual data is not optional.
Trade handling and honest scope travel together. The work runs through him as the contact, the quotation is written to pass to the end customer cleanly, and the prognosis is stated before commitment: if the failed disk images fully the whole volume returns, and if it does not, the striped damage spreads across the data and is reported by file. The end customer's relationship stays his — and the recommendation to rebuild the server on something other than a bare stripe travels with the recovered data.
Both SAS members were imaged under hardware write-blockers with SAS interfacing on the bench — the healthy member directly, the failed member assessed on PC-3000 UDMA and recovered by its fault, with clean-air donor work under laminar flow where mechanical. The RAID 0 was reassembled virtually from both images in UFS Explorer RAID, stripe geometry confirmed against the data, and the server volume and filesystem extracted, hash-verified, for delivery through the trade contact.
Both members imaged, the failed Cheetah recovered, and the stripe reassembled virtually with the server volume extracted. The assessment is free and the quote is a single fixed figure inclusive of VAT; where a drive has to be opened, half of the parts and labour is payable up front and the balance falls due only on success — otherwise it is no recovery, no fee. The decode: the healthy survivor holds half of everything and all of nothing. The recovery lives or dies on the failed disk's image — reassemble the pair correctly and the server's data comes back, then rebuild it on something safer than a stripe.
Don't rebuild or re-initialise the array and don't let the server try to — RAID 0 has no redundancy and a rebuild can overwrite recoverable data. The healthy survivor is not enough on its own; reassembly needs images of both members, so keep both and preserve their order. Note the controller and stripe details if you have them. And advise the end customer to move off a bare stripe for important data afterwards — a mirror or parity array would have survived this single failure.
Our case files are written up from genuine enquiries our lab has handled for customers across Staines, Surrey and the surrounding area, anonymised to protect client confidentiality. Each one describes the diagnostic and recovery approach our engineers apply to that fault, using the equipment listed.
Free diagnostic, fixed quote, no fix no fee — start now or call the freephone.