Storage Spaces Direct (S2D) Data Recovery
Storage Spaces Direct (S2D) is Microsoft's software-defined storage layer for Windows Server Failover Clustering, and forms the storage foundation of Azure Stack HCI, now branded Azure Local. Because S2D pools local disks across cluster nodes into shared virtual disks, recovery cases usually involve cluster database corruption, resiliency-tier exhaustion, or ReFS/CSVFS damage rather than a single physical drive fault.
Platform Lineage and Naming
Microsoft introduced Storage Spaces Direct with Windows Server 2016 as an evolution of the shared-nothing Storage Spaces feature, extending it to pool local, direct-attached disks across cluster nodes over the Software Storage Bus rather than relying on shared SAS enclosures. Windows Server 2019 and 2022 added features such as nested resiliency for two-node clusters and improved mirror-accelerated parity performance.
Microsoft subsequently packaged S2D as the storage layer of Azure Stack HCI, a hyper-converged infrastructure product validated on OEM hardware, which has since been rebranded Azure Local as part of Microsoft's broader Azure hybrid strategy. The underlying storage pool, virtual disk and CSVFS/ReFS mechanics remain consistent across the Windows Server and Azure Local product names.
- S2D — Storage Spaces Direct
- Azure Stack HCI — the earlier product name for the same HCI stack
- Azure Local — the current name for Azure Stack HCI
- Software Storage Bus (SSB) — the virtual SAS fabric connecting node-local disks
- CSVFS — Cluster Shared Volume File System (layered over ReFS or NTFS)
Generations and Models We Evaluate
| Generation / family | Models |
|---|---|
| Windows Server | Windows Server 2016, 2019, 2022 Storage Spaces Direct clusters |
| Azure Stack HCI / Azure Local | OEM-validated Azure Stack HCI 21H2/22H2 and Azure Local nodes |
| Cluster sizes | 2-node (with witness), 3-4 node, and larger scale-out clusters |
| Resiliency tiers | Two-way and three-way mirror, single/dual parity, mirror-accelerated parity, nested resiliency (2-node) |
Architecture and Data Layout
S2D aggregates local drives from each cluster node into a single storage pool over the Software Storage Bus, a clustered, virtualised SAS fabric that lets every node see every other node's local disks without external shared storage. Faster media (NVMe or SSD) is typically configured as an SBL (Storage Bus Layer) cache to absorb writes and reads ahead of slower capacity tiers.
Virtual disks (Storage Spaces) are carved from the pool with a chosen resiliency type — two-way or three-way mirror, single or dual parity, or mirror-accelerated parity blending both for balanced performance and capacity. These virtual disks are formatted with ReFS (recommended) or NTFS and exposed cluster-wide as Cluster Shared Volumes through CSVFS.
Cluster-wide configuration, including pool and virtual disk metadata, is held in the failover cluster database; corruption or loss of quorum in that database can render an intact pool inaccessible even though no physical data has actually been lost. Two-node clusters depend on a cluster witness (file share or cloud witness) to break ties during failover.
Protocols and formats: SMB3 (Cluster Shared Volumes), CSVFS over ReFS, CSVFS over NTFS, iSCSI/SMB Direct (RDMA) for cluster interconnect
- Resiliency is implemented at the virtual disk level as mirroring or parity across nodes and drives, distinct from RAID, with nested resiliency layering local and cluster-wide protection specifically for 2-node deployments.
- SBL cache devices absorb write I/O before destaging to capacity tiers; failure of a cache device with pending destage writes is a recurring factor in complex cases.
- ReFS provides built-in integrity streams and works with Storage Spaces to detect and, where redundancy allows, automatically correct certain forms of corruption.
Failure Scenarios
Logical failures
- Failover cluster database corruption preventing pool or virtual disk visibility
- Loss of cluster quorum on 2-node clusters after witness failure
- ReFS or CSVFS volume corruption despite an intact underlying pool
- Accidental virtual disk or volume deletion
- Failed Windows Server or Azure Local cumulative update leaving nodes out of cluster membership
- Storage pool configuration drift after improper node removal or re-addition
Hardware failures
- Multiple drive failures exceeding the configured resiliency tier
- SBL cache device failure with unflushed writes pending destage
- Node failures beyond what the mirror or parity configuration tolerates
- Network fabric failure disrupting Software Storage Bus connectivity between nodes
- Simultaneous node and witness failure on 2-node clusters
Encryption and credentials
S2D volumes can be protected with BitLocker; on Azure Local, keys may additionally be tied to Azure-based management. Key material and TPM/Azure key state should be preserved and documented before any recovery attempt on encrypted volumes.
What Not To Do Before an Evaluation
- Do not run rebuilds, reconstructions or re-initialisations against an array that has already lost more drives than its protection level allows.
- Do not recreate pools, aggregates, disk groups, storage pools or clusters — these operations write new metadata over the structures a recovery needs.
- Do not swap drives between slots, and do not reorder shelves. Record the original slot and shelf positions before removing anything.
- Do not run file-system repair tools against production volumes before the underlying storage layer has been evaluated.
- Do not restore a backup or replication set over the affected volumes until the recovery scope has been assessed.
- Do not eradicate deleted volumes or empty recycle/destroyed states on platforms that hold deleted data for a retention window.
Our Evaluation and Recovery Process
- Intake and platform identification — array model, generation, firmware, protection layout and the sequence of events that led to the failure.
- Read-only evaluation of the media and array structures, including assessment of drive health and the extent of any physical damage.
- Forensic imaging of all contributing media, with cleanroom work where drives require it. Originals are preserved unaltered.
- Reconstruction of the storage layer — pools, aggregates, parity groups, chunklets, extent groups or objects — from the images.
- Extraction of the layers above: file systems, virtual machines, databases, mailboxes and shares.
- Verification against a file list and customer-nominated critical data, followed by secure return on encrypted media.
Frequently Asked Questions
Is Storage Spaces Direct recovery the same as recovering a hardware RAID array?
No. Resiliency is implemented in software across pooled disks and nodes rather than a dedicated RAID controller, so reconstruction depends on the storage pool and cluster database metadata, not a RAID controller configuration.
Does Azure Local storage differ from on-premises Storage Spaces Direct?
Azure Local (formerly Azure Stack HCI) uses the same Storage Spaces Direct storage engine under the hood, so the pool, virtual disk and CSVFS/ReFS structures are consistent, though management and update tooling differ.
Our 2-node cluster lost the witness — is data at risk?
Losing the witness alongside a node failure can affect cluster quorum and therefore access to volumes, but it does not necessarily mean data has been physically lost; an evaluation of the pool and cluster database is needed to confirm state.