Save the Data First Then Decide Repair or Replace the Server Board

Every hour spent debating boards is an hour the data sits on drives in a dead chassis. Get it out, or prove it is backed up, first.

1. Start with the honest question: is there a current, tested backup? If yes, the rescue pressure drops enormously and the hardware decision becomes pure economics. If no, continue below — carefully.
2. Label every drive with its bay number before removal, photograph the cabling, and keep the set together. Order and membership are the array's memory.
3. Never let any system 'initialise', 'repair', or format a member drive during rescue attempts. Initialising writes new metadata over the array's own — that is the point of no return.
4. If the data is business-critical and the array state is uncertain (multiple drives flagged, a rebuild interrupted), stop and price a professional recovery lab against the data's value. That is sometimes the honest answer, not a defeat.

Drives from a dead board are usually healthy drives. The array's enemy is not the failure — it is haste.

Most RAID setups store their configuration on the drives, which is what makes rescue possible at all.

1. Hardware RAID: a controller of the same family (often the same or a compatible model) detects the drives' metadata as a 'foreign configuration' and offers to import it. Import — never create a new array over the members. Keep the same drive order where the controller cares about it.
2. Software RAID (Windows Storage Spaces, Linux mdadm): the host OS can usually reassemble the array read-only or normally once all members are attached. Linux will assemble mdadm arrays from a live boot for inspection and copying.
3. ZFS and similar pools: pools import on another host with their labels; import read-only first if the pool's state is in doubt.
4. Whatever the flavour: first contact is for copying data off, not for resuming production. Mount, verify the important folders open, copy to safe storage, and only then consider running anything from the rescued set.

If the array imports and the files read, your incident just shrank from 'data loss' to 'hardware shopping'. That difference is the whole value of doing this step calmly.

With the data safe, the hardware decision becomes honest arithmetic. Option one is repairing the board you have:

1. Component-level work — capacitors, MOSFETs, regulator stages — is specialist rework on multi-layer server boards. It needs the right station, donor parts, and a technician who does it daily. Ask for their success terms; honest shops charge diagnosis when a board proves unrepairable.
2. Repair preserves everything: same platform, same RAID controller identity, same OS and drivers, licensing untouched. When it succeeds it is the lowest-disruption path.
3. Its risks are time and certainty: days in a queue, and a repaired power stage on an aged board can be followed by the next aged component. A repair warranty period matters — ask for it in writing.

Repair is strongest when the board is rare, expensive, or welded into a validated setup — weakest when the board is common and the server earns money daily.

Option two is a replacement board. The fork inside it matters more than the part price:

1. Same-model board: the drop-in path. Same CPU and RAM move over, the RAID and OS usually wake up as if nothing happened, and downtime is measured in hours. For most working servers this is the benchmark every other option must beat.
2. Different platform: the cascade hides here — a newer board can require a new CPU family and a new RAM generation, the OS may need new storage drivers to boot at all, and licences tied to hardware may need attention. Price the cascade, not the board.
3. A complete donor machine of the same model often undercuts a bare board and donates PSU modules, fans, backplanes and rails besides. For ageing fleets it is frequently the smartest single purchase.
4. Buying used boards: insist on a tested, returns-accepted listing, and plan to burn the board in for a day before it carries production again.

Write the comparison as three numbers per option: money out, hours down, and risk carried. The cheapest part is regularly the most expensive option.

Decide, execute, and then close the loop that caused the pain:

1. If the data was never backed up and this incident scared you — it was meant to. A dead board should be an inconvenience story, not a data story. Set up the backup the week the server returns, while the lesson is warm.
2. Keep the dead board until the replacement has run a full week. It is a parts donor and, occasionally, evidence that your verdict was wrong.
3. Log the failure for the fleet: model, age, failed stage, and the telling symptom (cold CPU). Patterns across a fleet are how the next failure gets predicted instead of suffered.
4. However it ends, the method held: power proven, machine stripped, witnesses read, data rescued, decision priced. That order is the difference between a diagnosis and a guess with a purchase order attached.

A server dying is an expense. A server dying with its data unrescued and its replacement unpriced is a crisis. The order of operations is what separates them.