Controllers and hosts, and what each one says when it fails. The name decides the messages. The metadata decides the job.

Two things decide how an array job turns out, and the controller is neither of them. The first is how many members still read, and whether the one that failed first was kept. The second is what was done between the failure and the parcel: a rebuild started onto survivors bought on the same day as the drive that died, a foreign configuration cleared to tidy the screen, F2 pressed at a 1779 prompt, a stale drive forced online, a pool rewound with -F on the originals, a new virtual disk created over the old one and initialised, chkdsk run on a volume assembled with the wrong stripe. Each of those is a page of its own under what the controller says, in the vendor's own words.

The pages here are organised by controller and host because that is what is on the screen, and written around the metadata each one keeps on the drives, the defaults each one uses, and the dated advisories that hit each one's owners, with document numbers, because that is what the bench needs and what the forums get wrong. The array itself is reassembled the same way whatever wrote it: every member imaged, the geometry read from the metadata or recovered from the parity, the set assembled in software from the images, and the file system repaired on a copy of the virtual volume. How a RAID array is rebuilt from member images goes through it in order.

None of the controller makers runs a recovery laboratory for arrays. Dell withdrew its data recovery service in 2022, and it only ever covered client PCs; HPE, Broadcom and Microchip offer none; the software projects are open source and offer their mailing lists. What Dell and HPE do offer is drive retention on a support contract, so that the failed drive stays with you, and that is the thing to have, because the recovery is done here. The parent site's server recovery page covers the server as a whole.