Something has to run your array: a dedicated controller card, the motherboard's built-in RAID, or Windows Storage Spaces. They differ most on the two days that matter - the day power fails, and the day the controller does.
RAID levels get the attention, but the component that implements them decides how your array behaves under power cuts, failures and repairs. There are three realistic choices for a Windows Server: a dedicated hardware RAID controller, motherboard RAID (the kind built into the chipset and BIOS), and Windows Storage Spaces, Microsoft's software RAID. This comparison grades them honestly, including the two facts marketing leaves out: a write cache without battery or flash protection is a corruption risk, and a hardware array can become unreadable when its controller dies. And as everywhere in this set: whichever you choose, the array is still not your backup.
A proper RAID card has its own processor and memory. The parity maths for RAID 5 and 6 happens on the card, not your CPU, and the cache absorbs bursts of writes so the server feels fast. That cache is the catch. In write-back mode the card tells Windows "saved" while the data is still only in the card's memory - and if power dies in that moment, the data is gone and the filesystem may be corrupt. The fix is protection for the cache: older cards use a battery backup unit (BBU), newer ones use flash-backed write cache (FBWC) that saves the cache to flash on power loss. A dedicated card with BBU or FBWC is the best-performing, safest way to run parity RAID. The same card with an unprotected cache is a liability. When buying, the protection is not an optional extra - it is the point. Batteries also age; a card reporting a failed BBU has silently dropped to slow, safe write-through mode, which is the correct failure behaviour - check its status in the controller utility, not just when users complain the server went slow.
An array's layout - which drives, which level, stripe sizes - is recorded in metadata written by the controller. Drives from a hardware array generally cannot be read by plugging them into a random PC, and often not even by a different brand of controller. The recovery path is a replacement controller of the same family, which then imports the "foreign configuration" from the drives. For a production server this means two practical habits: buy controllers that are common and current, so a replacement exists when you need one, and record the exact model and firmware on the paper plan. None of this is a reason to avoid hardware RAID - it is the price of its performance - but you should pay it knowingly, and it is one more reason the separate backup matters: the backup does not care which controller wrote it.
Most server and desktop boards offer "RAID" in the BIOS, implemented by the chipset and a driver. It costs nothing, and for a server it is worth roughly that. The parity and rebuild work falls on your CPU and a fragile driver layer; features like cache protection do not exist; a BIOS update or a driver problem can put the array at risk; and the metadata is no more portable than a real card's. Its one honest use is a simple mirror for a non-critical machine where the budget is truly zero - and even there, Windows can mirror the drives itself (as below) with fewer surprises. If a vendor quotes you a "server" whose RAID is the motherboard's, ask what changes when the board dies. The answer is why this section exists.
Storage Spaces is software RAID built into Windows Server: you pool drives and create spaces that are simple (striped), mirrored, or parity-based. Its strengths are real. There is no controller lock-in - move the drives to another Windows machine and the pool imports, which makes the controller-death disaster largely disappear. It costs nothing beyond the drives. Mirrored spaces are honest, solid performers for file services and Hyper-V in small offices, and thin provisioning lets volumes grow as pools do. Its weaknesses are equally real: parity spaces write slowly - traditionally much slower than a cached hardware card - so databases and heavy VM storage are not their home; there is no battery-backed cache, so safe write behaviour leans on a good UPS; and the tooling, while much improved, asks more knowledge of you than a controller utility. For an office that values simplicity and recoverability over raw write speed, a Storage Spaces mirror is a defensible, even sensible, design. For parity or heavy write loads, the protected hardware card wins.
A short decision order:
Whatever wins, write the choice and the exact model on the paper plan, and make sure the backup exists independently of it.
Controllers, drives and RAID levels in the full hardware tour - watch the complete video before your install.
Watch Full VideoBoth protect a RAID card's write cache when power fails. A BBU (battery backup unit) keeps the cache memory alive with a battery until power returns - batteries age and need checking. Flash-backed write cache (FBWC) copies the cache contents to non-volatile flash on power loss, using a capacitor for the few seconds of power needed. Flash-backed is the modern, lower-maintenance option.
With hardware RAID, generally not on an ordinary PC - the array metadata belongs to that controller family, so the usual recovery is a same-family replacement card importing the configuration. Windows Storage Spaces is the kinder case: its pool can be imported by another Windows machine. Either way, an independent backup removes the drama entirely.
Yes, in a mirror layout, with a good UPS and a tested backup. Mirrored Storage Spaces are simple, portable between Windows machines and free of controller lock-in. Where it falls short is parity write performance - heavy database or VM write loads are better served by a hardware controller with a protected cache.