Three disks, one of them dead, and no one remaining in the business who knew how this array had been set up. It would have been a short answer if this was striped. First, we had to determine what it really was.
This is a scenario, not a case study. It illustrates a common failure type that we address on a regular basis, and how it is approached, written from the technical side (versus as part of a single customer project). Please visit our documented case files here.
A software array (Windows Storage Spaces, dynamic disks, Linux mdadm, or a ZFS pool) will not import. The host that created the array failed, or the OS was reinstalled, and there is nothing left that knows how to recreate the volume layout.
Hardware RAID retains its configuration on a controller. Software RAID retains it on the members. This is an actual advantage: the disks retain their own configuration information and can often be assembled on totally different hardware.
Linux's mdadm writes a superblock onto each member of the array describing the array's UUID, RAID level, chunk size and role. ZFS puts labels on either end of all vdev members. Microsoft's Storage Spaces retains pool information as a record across each physical disk. In each case, the information needed to rebuild is still there rather than lost with the machine.
Usually what does go wrong isn't going to be your metadata; most often it is an attempt at fixing something. When you force an import, recreate a pool using the exact same parameters, or have Windows convert the disks back to “basic”, this always writes over the original metadata description.
The only way is through recovery of the actual disk that failed. RAID 0 has no parity and no mirror, so nothing exists to calculate the missing stripes. Your only choice is to get that physical disk working again. If it is genuinely destroyed, then that portion of every file is gone.
There is nothing unusual about this: it is just the standard starting point. The layouts were originally recorded onto the disks themselves and can be read back. Regardless of what anyone recalls, stripe size, member order, and whether disks were mirrored or striped are all determined by comparing the images.
You compare them (the disks) directly. Identical data will be stored at exactly the same offset for mirrored disks. Different data will alternate with each block for striped disks. This distinction becomes apparent within a few megabytes of comparison.
Generally no. A Windows software RAID stores its configuration as metadata on the disks. If one member of the RAID goes away, the OS often stops showing you the RAID altogether, but all the other members still have intact data.
No. Plugging back in an intermittently failing member may cause the OS to attempt to write to the array or sync it in the wrong direction. Shut off power and image each disk before attempting to do anything else.
From £500 plus VAT; all necessary diagnostics prior to quoting are free (diagnostics take up to 48 hours), and the price is then fixed in writing. If any of your hard drives need mechanical work, a 50% payment is made prior to that work being done. The balance is due only upon successful completion of the recovery.
Each member is imaged first. Then on-disk metadata is read directly instead of asking the host to import it: superblock, label, or pool structure parsing occurs to determine the RAID level, ordering, chunk size, and offset of each member.
If the metadata was damaged, then the same methodology applied to hardware RAID applies here: test candidate configurations against file system structures until the correct configuration is found.
Images are then used to assemble the volume, never the original disks.