Storage Spaces Direct: what actually breaks, and how it tells you

Storage Spaces Direct is, in my experience, better at reporting its own state than most people are at reading the report. The health service knows what is wrong. The failure is usually that somebody looked at one volume, saw “degraded”, and started making changes while a repair job was already running.

The single most valuable habit with this technology is: read the whole state before changing any of it, and specifically check whether the cluster is already fixing the problem itself.

The symptoms, and why they overlap

Four reports arrive, and they are frequently the same underlying event:

• A volume is degraded or in a warning state.
• Virtual machines are slow, or their storage latency has increased.
• A physical disk shows as unhealthy, lost communication, or retired.
• A node was restarted and storage has not returned to healthy.

The overlap exists because Storage Spaces Direct responds to a fault by automatically starting a repair, and the repair itself consumes throughput. So “a drive failed” and “everything is slow” are often one event observed at two moments.

The architecture that produces the behaviour

Worth having in mind before reading any output.

Physical disks across all nodes form a storage pool. Volumes are virtual disks carved from that pool, with a resiliency type — two-way mirror, three-way mirror, parity, or mirror-accelerated parity — that determines how many copies exist and where.

Copies are placed across fault domains, which default to nodes. A three-way mirror keeps three copies on three different nodes, so it tolerates two node failures. A two-way mirror keeps two copies and tolerates one.

When a disk or a node is lost, the data is still available from the surviving copies — the volume is degraded, not offline — and the cluster begins repairing by rebuilding copies onto remaining capacity. That repair needs somewhere to write, which is why the pool must keep reserve capacity free. A pool with no reserve cannot repair, and a degraded volume stays degraded until capacity appears.

Two mechanisms matter for diagnosis:

• The health service aggregates faults into readable reports rather than requiring you to assemble them.
• Storage jobs are the asynchronous work — repairs, rebalances — and their progress is visible.

Diagnosis: the sequence, in order

Do not start with the volume somebody complained about. Start with the whole system.

1. Ask the health service what it thinks

Get-StorageSubSystem -FriendlyName 'Clustered Windows Storage*' | Get-StorageHealthReport
Get-StorageSubSystem -FriendlyName 'Clustered Windows Storage*' | Debug-StorageSubSystem

Debug-StorageSubSystem is the one to know. It returns the current faults with a description and a recommended action, in plain language. It is the fastest route to the actual problem and it is consistently underused.

2. Check whether a job is already running

Get-StorageJob

This is the step that prevents most self-inflicted damage. If a repair is in progress, the correct action is usually to let it finish. Restarting nodes, retiring disks or forcing repairs while a job is running extends the degraded window and can create a second fault.

A job that is progressing slowly is normal for a large rebuild. A job stuck at the same percentage across several checks is not, and needs investigation rather than patience.

3. Look at the physical disks

Get-PhysicalDisk | Select-Object FriendlyName, SerialNumber, MediaType, Size,
    HealthStatus, OperationalStatus, Usage |
    Sort-Object HealthStatus, OperationalStatus

The two status columns mean different things and both matter:

• HealthStatus — Healthy, Warning, Unhealthy.
• OperationalStatus — the more specific condition: OK, Lost Communication, Removing from Pool, Starting Maintenance Mode, Stale Metadata, Unrecognized Metadata.

Lost Communication usually means a connectivity or enclosure fault rather than a dead drive. Stale Metadata frequently resolves itself once a repair completes. Reading the operational status rather than only the health status is what distinguishes “replace this drive” from “wait”.

4. Check the pool and its free capacity

Get-StoragePool -IsPrimordial $false | Select-Object FriendlyName, HealthStatus,
    OperationalStatus, Size, AllocatedSize

Get-VirtualDisk | Select-Object FriendlyName, ResiliencySettingName,
    HealthStatus, OperationalStatus, Size, FootprintOnPool

If the pool has insufficient free capacity, repairs cannot complete and everything downstream stays degraded. This is a design failure surfacing as an operational one, and no amount of troubleshooting fixes it — you need capacity.

5. Confirm the cluster itself is well

Get-ClusterNode | Select-Object Name, State, StatusInformation
Get-ClusterSharedVolume | Select-Object Name, State, OwnerNode
Get-ClusterNetwork | Select-Object Name, State, Role

Storage Spaces Direct depends on the cluster network for east-west storage traffic. A network fault presents as a storage fault, and on RDMA-configured clusters a misbehaving adapter or a switch configuration change is a genuinely common root cause.

Interpretation: the four things that actually break

A drive fails. The common, designed-for case. The volume degrades, a repair starts automatically, and the cluster continues. The correct response is to confirm the repair is running, replace the drive, and confirm the pool returns to healthy. Do not intervene beyond that.

The pool runs out of reserve capacity. Repairs cannot complete. This presents as a volume that will not return to healthy and jobs that do not progress. The cause is a design decision made earlier — insufficient reserve for the failure being tolerated. Adding capacity is the fix; there is no clever alternative.

The network degrades. Increased latency, storage jobs crawling, intermittent cluster communication warnings. On RDMA configurations, confirm the switch configuration is still what it was — a change to flow control or quality of service on the switch will produce exactly this, and the cluster will not tell you a switch changed.

A node comes back with stale data. After an unplanned restart, the node’s copies are behind and must be resynchronised. Storage jobs run and volumes are degraded until they complete. This is normal and it takes as long as it takes. Restarting another node during resynchronisation is how a tolerable situation becomes an outage — with a two-way mirror or after an earlier failure, you may have less redundancy remaining than you assume.

Resolution

For a failed drive, use maintenance mode properly rather than pulling hardware:

# Take the disk's node out of service correctly before physical work.
Suspend-ClusterNode -Name 'NODE02' -Drain

# After the physical replacement and the node returns.
Resume-ClusterNode -Name 'NODE02' -Failback Immediate

For a specific disk being retired, Set-PhysicalDisk -Usage Retired marks it so data moves off it, and the pool then repairs onto other capacity. Confirm the pool has room first — retiring a disk in a pool without reserve leaves you worse off.

For a volume that is degraded after the cause is resolved, Repair-VirtualDisk triggers the repair explicitly. Use it when a repair has not started on its own, not to hurry one that is already running.

The one thing not to do: reboot nodes to clear a storage fault. It is the reflex from other technologies and it is actively harmful here, because it removes copies from a system that is already short of them.

Validation

Do not close it on the volume returning to healthy alone. Confirm:

• Get-StorageJob returns nothing outstanding.
• Get-PhysicalDisk shows every disk Healthy and OK, with the expected count.
• Get-VirtualDisk shows every volume Healthy, and the resiliency is what it should be.
• Debug-StorageSubSystem returns no faults.
• Pool free capacity is back above your reserve threshold.
• The cluster survives a planned node drain, tested deliberately once things are calm.

That last one is the real validation. A cluster that reports healthy but cannot tolerate losing a node has not recovered; it has stopped complaining.

Operations

Monitor free pool capacity as a first-class metric, with an alert well before the reserve is consumed. This single alert prevents the second failure mode above entirely.

Alert on storage jobs that run beyond an expected duration, and on any physical disk leaving OK.

Patch nodes one at a time, with full health confirmation between, using cluster-aware updating. The temptation to speed up a maintenance window by draining two nodes is how three-way mirror clusters end up with a single copy.

Keep the drive firmware and driver levels consistent across nodes, and within the vendor’s validated set. Mixed firmware is a genuine source of intermittent, difficult faults.

Verification and limits

The health service and Debug-StorageSubSystem, storage job behaviour, physical disk health versus operational status, pool reserve capacity requirements for repair, fault domain placement and maintenance mode handling were checked against current Microsoft documentation on 20 September 2026. The diagnostic ordering reflects how I work through these faults.

Nothing here was executed against a cluster for this article. The read-only commands are safe. Set-PhysicalDisk -Usage Retired, Repair-VirtualDisk, node suspension and any physical replacement all affect a system that is by definition already carrying reduced redundancy — confirm current backup evidence, check Get-StorageJob first, and change one thing at a time. Output and behaviour vary by release, so confirm the expected state for your build.

References

• Storage Spaces Direct overview
• Troubleshoot Storage Spaces Direct health and operational states
• Fault tolerance and storage efficiency
• Plan volumes in Storage Spaces Direct