Three disks, one dead, and nobody left in the business who knew how the array had been set up. If it was striped the answer was going to be short — so establishing what it actually was came before anything else could happen.
This is a scenario, not a case study. It describes a failure pattern we handle regularly and how it is approached, written from the technical work rather than from one client's job. Our documented case files are here.
An array built in software — Windows Storage Spaces, dynamic disks, Linux mdadm, or a ZFS pool — stops importing. The host that assembled it has failed, or the operating system has been reinstalled, and nothing remains that knows how the volume was arranged.
Hardware RAID keeps configuration on a controller. Software RAID keeps it on the members, which is a genuine advantage: the disks carry their own description and can frequently be assembled on entirely different hardware.
mdadm writes a superblock to each member recording the array UUID, level, chunk size and device role. ZFS writes labels at both ends of every vdev member. Storage Spaces records pool metadata across the physical disks. In each case the information needed to rebuild is present rather than lost with the machine.
What goes wrong is usually not the metadata but an attempt to fix things. Forcing an import, recreating a pool with the same parameters, or letting Windows convert disks back to basic all write over that description.
Every member is imaged first. The on-disk metadata is then read directly rather than asking the host to import — superblocks, labels or pool structures parsed to establish level, order, chunk size and offsets.
Where that metadata has been damaged, the same geometry-derivation methods used on hardware RAID apply: test candidate parameters against file system structures until the arrangement that makes sense is found.
The volume is then assembled from images, never from the original disks.