The scariest part of a dead board is not the board — it is the data behind it. This page explains why an identical-board swap on the ST150 normally brings your RAID array and operating system back untouched, the discipline that keeps it that way, and the three exceptions worth knowing before you start.
A replacement board raises one question that outranks price, speed and everything else: does my data come back with it? For the ST150 the answer is genuinely good, and it is not luck — the platform stores its RAID configuration on the disks, and a correct replacement board reads it like a letter addressed to it. This page explains the mechanism, gives you the labelling discipline that protects it, lists what legitimately changes (activation, MAC addresses, BIOS settings), and names the exceptions plainly so there are no surprises at first boot.
👆 The data survives because the array description lives on the disks. What changes is the board identity around it — settings, addresses and activation.
When an ST150 board dies, the server is a box of other people's priorities suddenly: accounts data, a file share, maybe the office's only application. So the first question is never really "can the board be replaced" — it is "if I replace it, does everything come back?" On this platform the honest answer is reassuring: yes, in the normal case, provided the replacement is a correct ST150 board and the disks go back in their original positions. Here is why, and where the exceptions hide.
The ST150's onboard RAID is Intel chipset software RAID (levels 0, 1, 5, 10). Its important design fact: the array's description — which disks belong, in what order, at what level — is written on the disks themselves, not held only in the board. A replacement ST150 board with the same onboard controller reads that metadata at first power-on and recognises the array as its own. This is the same reason the array would not be understood by a random different platform: the new home must speak the same RAID language, which is one more reason the replacement must be a genuine ST150 board and not a workaround.
The data survives; the board's identity does not, and a few things honestly follow from that. The new board has different network MAC addresses, so DHCP reservations and anything bound to the old MAC need updating. Windows may ask to reactivate, because a motherboard is the core of its hardware identity — normally a routine online or phone activation with the same licence. BIOS settings return to defaults: boot order, fan and power behaviour, and any tuned options must be set again from your notes (another reason the pre-swap photographs matter). None of this touches the data itself — it is an afternoon of administration, not a recovery project.
Three situations break the happy path and deserve honesty. First, if the original failure involved power surging through the machine, a disk may have died with the board — the array then boots degraded or not at all, and the problem is a disk, not the swap. Second, a RAID 0 array has no redundancy by design: one dead member means the data is gone regardless of boards, which is why RAID 0 was never a place for the only copy of anything. Third, if the replacement board is a different platform (the workaround idea), all bets are off — different controller, unrecognised metadata, real data-recovery territory. Same board, labelled disks, patient first boot: that is the whole secret.
See the ST150 board replacement in the video, including the first boot with the original drives.
▶️ Watch Full VideoNo, in the normal case. The array configuration is stored on the disks themselves, and a genuine replacement ST150 board with the same onboard controller reads it and recognises the array. Label every drive position before the swap and never accept any prompt to initialise or create a new array.
Normally not. The same storage controller and platform means Windows or Linux boots on the replacement board as it did before. Windows may ask to reactivate because the motherboard defines its hardware identity, and you will need to redo BIOS settings such as boot order — but the installation and data carry over.
Check the simple things first: storage mode in BIOS set to RAID rather than AHCI, all drive cables and positions exactly as labelled, and every disk spinning up. Never initialise anything. If the array is still invisible, stop and treat it as a data-recovery situation rather than experimenting further.