Skip to content
WindowsHow-To Published Updated 5 min readViews unavailable

How to Set Up Storage Spaces for Redundant Storage on Windows

Pooling multiple physical drives into a resilient virtual disk — Windows' built-in, software-defined answer to hardware RAID, set up step by step.

Storage Spaces pools multiple physical disks into flexible virtual disks with configurable redundancy — a software-defined alternative to hardware RAID controllers, built directly into Windows.

Step 1: identify the physical disks to pool

Get-PhysicalDisk

Disks intended for a storage pool should be unformatted/unpartitioned — Storage Spaces takes ownership of the raw disk, not an existing partition on it.

Step 2: create a storage pool from the physical disks

$disks = Get-PhysicalDisk -CanPool $true
New-StoragePool -FriendlyName "MyPool" -StorageSubsystemFriendlyName "Windows Storage*" -PhysicalDisks $disks

The pool itself is just a container — it doesn’t yet define redundancy behavior; that’s configured per virtual disk created from the pool.

Step 3: understand the resiliency options before creating a virtual disk

Simple    — no redundancy, striped across disks (fastest,
            no protection against a disk failure)
Mirror    — data duplicated across disks (protects against
            failure, at the cost of usable capacity)
Parity    — distributed parity like RAID 5 (better capacity
            efficiency than mirror, slower write performance)

Step 4: create a virtual disk with the chosen resiliency

New-VirtualDisk -StoragePoolFriendlyName "MyPool" -FriendlyName "MyMirrorDisk" -ResiliencySettingName Mirror -Size 500GB

Step 5: initialize and format the new virtual disk

Get-VirtualDisk -FriendlyName "MyMirrorDisk" | Get-Disk | Initialize-Disk -PartitionStyle GPT -PassThru | New-Partition -AssignDriveLetter -UseMaximumSize | Format-Volume -FileSystem NTFS

Step 6: verify pool and virtual disk health

Get-StoragePool -FriendlyName "MyPool" | Get-VirtualDisk

Check the HealthStatus field — this is what you’d monitor going forward for signs of degradation.

Step 7: simulate and understand failure recovery, for Mirror or Parity configurations

With a redundant configuration, physically removing (or in testing, marking offline) one disk should leave the virtual disk accessible, though in a degraded health state — confirming this in a controlled test, rather than assuming it works, is worth doing before relying on it in production.

Step 8: add a replacement disk after a failure

Add-PhysicalDisk -StoragePoolFriendlyName "MyPool" -PhysicalDisks (Get-PhysicalDisk -CanPool $true)

Storage Spaces then repairs the redundant virtual disk onto the new physical disk automatically.

Step 9: monitor pool health going forward

Get-StorageJob
Get-PhysicalDisk | Select FriendlyName, HealthStatus, OperationalStatus

Why choosing resiliency level deliberately matters more than the setup commands

Simple, Mirror, and Parity trade off capacity, performance, and failure tolerance very differently — Simple offers no protection at all despite being the fastest and most space-efficient, while Mirror sacrifices roughly half of raw capacity for straightforward, fast-to-rebuild redundancy. Picking based on which trade-off actually matches your data’s importance and your available disk budget, rather than defaulting to whichever option a guide happened to demonstrate, is the actual decision that determines whether Storage Spaces protects you when a disk eventually fails.

Understanding thin provisioning, Storage Spaces’ default allocation model

By default, a Storage Spaces virtual disk is thin provisioned — you can create a virtual disk advertising more capacity than the pool currently physically contains, with actual physical space only consumed as data is genuinely written, similar in spirit to the thin-provisioning pattern covered for Linux’s LVM elsewhere on this blog. This is useful for planning ahead (creating a virtual disk sized for anticipated future growth without needing all the physical disks present on day one) but carries the identical real risk that pattern always carries: if the pool’s actual physical capacity fills up before you’ve added the additional physical disks the thin-provisioned virtual disk was implicitly counting on, writes begin failing regardless of what the virtual disk’s advertised size suggests should still be available. Monitoring actual pool free space directly (Get-StoragePool | Select-Object Size, AllocatedSize), not just the virtual disk’s advertised capacity, is essential specifically because of this gap between advertised and physically available space.

Setting up write-back caching with a fast tier disk

For a pool mixing fast SSDs and larger, slower HDDs, Storage Spaces supports storage tiering, automatically placing frequently-accessed (“hot”) data on the faster SSD tier while colder, less-active data migrates to the larger HDD tier — combining SSD-like performance for active data with HDD-like cost-per-gigabyte for a pool’s bulk capacity:

New-StorageTier -StoragePoolFriendlyName "MyPool" -FriendlyName "SSDTier" -MediaType SSD
New-StorageTier -StoragePoolFriendlyName "MyPool" -FriendlyName "HDDTier" -MediaType HDD

This tiering happens automatically and periodically based on observed access patterns, rather than requiring manual intervention to decide which specific files belong on which tier — a meaningful practical benefit for a pool where budget favors a small amount of fast SSD capacity paired with considerably more affordable bulk HDD storage, rather than needing to choose one media type exclusively for the entire pool.

Renaming or resizing an existing virtual disk

Resize-VirtualDisk -FriendlyName "MyMirrorDisk" -Size 750GB
Resize-Partition -DriveLetter D -Size (Get-PartitionSupportedSize -DriveLetter D).SizeMax

Growing a virtual disk (provided the underlying pool has sufficient free space, or additional physical disks are added first) and then extending the actual partition and filesystem to use that new space are two genuinely separate steps — resizing the virtual disk alone doesn’t automatically grow the NTFS volume sitting on top of it, which is why both commands are needed together, run in that specific order, to actually make the additional space usable rather than leaving it allocated to the virtual disk but genuinely inaccessible to the NTFS filesystem actually sitting on top of it.

Related:

Sources:

Comments