More and more businesses are moving away from traditional RAID arrays or dedicated SANs in favour of Storage Spaces Direct (S2D), the software-defined storage technology built into Windows Server since the 2016 release. The appeal is clear: pool the local storage of several standard servers into a single virtual storage space, with no proprietary storage hardware required. But this operational simplicity comes with a trade-off that’s rarely mentioned: when something goes seriously wrong, recovering data from an S2D cluster is significantly more complex than a classic RAID recovery.
Storage Spaces and Storage Spaces Direct: two different things
Storage Spaces on its own has existed since Windows Server 2012: it’s a software layer that virtualises drives attached to a single machine, similar to a software RAID built into the OS. Storage Spaces Direct (S2D) goes further: it combines the local storage of several servers (from 2 to 16 nodes) into a single shared pool over the network, without an external storage array or shared SAS cabling. Each node sees every other node’s drives as if they were directly attached to it.
How an S2D cluster actually works
The architecture stacks several distinct software layers. First, the Software Storage Bus, which connects the physical drives of every node over the network and replaces the Fibre Channel or shared SAS cabling of a traditional array. Next comes the storage pool, which automatically groups all eligible drives. On top of that, Storage Spaces creates virtual disks with a chosen fault tolerance scheme (mirroring or parity). Finally, the ReFS (or NTFS) file system and the Cluster Shared Volumes (CSV) layer make these volumes appear as locally mounted on every server, relying on the SMB 3.0 network protocol. That’s five distinct software layers between the physical drive and the final file, compared to a single layer (the RAID controller) on a classic array.
Caching plays a central role in this architecture: the fastest drives in a node (SSD or NVMe) automatically cache reads/writes for the capacity drives (slower SSDs or mechanical drives), boosting performance. Microsoft recommends at least 4 GB of RAM per TB of cache drive capacity to handle the associated metadata, and requires cache drives to be at least 32 GB.
Capacity limits depend heavily on the Windows Server version
A common source of confusion: S2D’s maximum capacity has increased significantly across versions. On Windows Server 2016, the limit was 100 TB of raw capacity per server and 1 PB (1,000 TB) per pool. Since Windows Server 2019, those ceilings have risen to 400 TB per server and 4 PB (4,000 TB) per pool, still on a cluster of up to 16 servers. An older S2D cluster that has never been upgraded since its initial deployment may therefore be operating under very different constraints than a recent one — worth knowing before any diagnosis, including in the event of a failure.
| Version | Max. raw capacity per server | Max. pool capacity |
|---|---|---|
| Windows Server 2016 | 100 TB | 1 PB (1,000 TB) |
| Windows Server 2019 and later | 400 TB | 4 PB (4,000 TB) |
Built-in resiliency doesn’t eliminate the risk of data loss
S2D protects data through mirroring (two or three copies spread across different servers) or parity, on a principle similar to RAID 1 or RAID 5/6, but applied at the cluster level rather than within a single array. A properly configured cluster typically tolerates two simultaneous drive or server failures (usually with three-way mirroring). This resiliency protects against isolated hardware failure — not against everything else: a number of simultaneous failures beyond what was configured, a manipulation error during a drive replacement, a logical corruption that propagates before it’s detected, or an initial configuration flaw (insufficient mirroring on an all-flash pool, for example) remain very real data-loss scenarios, despite the native resiliency.
Why recovering an S2D cluster is more complex than a classic RAID
On a traditional RAID array, an engineer rebuilds a volume by working on a single layer: how data is laid out across the physical drives according to the RAID algorithm used. On an S2D cluster, one has to reconstruct, in turn, the storage pool spread across several servers, then the virtual disks with their own resiliency scheme, then the CSV/ReFS file system, before even reaching the files or the virtual disks of the virtual machines hosted on top. Each additional software layer is a point where the link between a piece of data and its actual physical location can break, particularly if an automatic repair attempt has already been triggered by the cluster before any intervention.
On hyperconverged clusters hosting virtual machines (Hyper-V) on this same infrastructure, complexity gets an extra layer: beyond the virtualised storage itself, the consistency of the VMs’ own virtual disks must also be restored. A database hosted on a VM whose underlying S2D storage was corrupted illustrates this layering well — a case broadly comparable, in terms of complexity, to what we describe in our article on a database lost after a corrupted VM.
What not to do when an S2D cluster raises an alert
- Don’t trigger an automatic pool rebuild before precisely identifying which drives and which nodes are actually affected: on an architecture spread across several servers, a rebuild started on the wrong assumptions can turn a recoverable situation into a lost one.
- Don’t remove or replace several drives across several nodes at the same time without prior advice, even if the management interface (Windows Admin Center, PowerShell) technically allows it.
- Don’t overlook the network: since nodes communicate continuously over SMB 3.0 on dedicated 10 GbE or RDMA links, a network issue can look like a storage failure even when the drives themselves are intact — worth ruling out before any physical intervention.
When to call in a specialised lab
As soon as an S2D cluster becomes inaccessible, an automatic repair attempt has failed, or the number of failed drives/nodes exceeds the configured tolerance, every further manipulation reduces the chances of recovery. A lab familiar with RAID and virtualised storage can work layer by layer — Software Storage Bus, pool, virtual disks, file system — rather than relying on the cluster’s built-in automatic repair, which isn’t designed for a scenario where native resiliency has already been exceeded.
Storage Spaces Direct remains a robust technology, built to tolerate common hardware failures without service interruption. But its flexibility comes at a cost once a failure exceeds what was planned for: more software layers mean more ways for the link between a piece of data and its physical storage to break, and an improvised rebuild can turn a recoverable failure into a total loss.