Storage Spaces and ReFS on a Windows Server: When Mirrored Volumes Beat a Single Data Disk

A second data disk is the cheapest upgrade on a Windows VPS, and for a surprising number of workloads it is also the correct one. Storage Spaces earns its complexity only when you need redundancy a single volume cannot provide — and inside a VM the redundancy story differs from a physical server, because the hypervisor already provides much of it.

The decision is whether mirrored spaces, ReFS integrity streams and their rebuild cost beat one plain NTFS volume on provider-managed SSD. This guide covers the mechanics, the resiliency modes and the workloads where each wins. See the Windows VPS plans overview for how disk tier and snapshot policy affect the choice.

What a single data disk actually gives you

A single data disk is usually a virtual block device on the provider’s storage tier, often NVMe or enterprise SSD with redundancy underneath. It arrives as one NTFS volume with predictable latency and no parity calculations. Drive letters are stable, snapshots are taken at the hypervisor, and every backup tool understands it.

Its weakness is equally simple: from the guest’s perspective the volume is one failure domain. If filesystem metadata is corrupted, there is no second copy inside the machine. Snapshots help but are not backups and are not immune to a compromised guest. That distinction — provider redundancy versus in-guest redundancy — drives everything.

What Storage Spaces adds, and what it costs

Storage Spaces pools disks and creates virtual disks on top with a resiliency setting. On a VPS you attach two or more data disks, build a pool, and mirror it. The guest then holds two copies of every write, so one disk failure is survivable without a snapshot restore. You can add capacity later by attaching another disk and extending the virtual disk.

The cost is real. A two-way mirror halves usable capacity, so 2 x 100 GB gives roughly 100 GB. Every write is duplicated, which adds latency that a busy SQL Server shows as higher write waits. Rebuilds consume I/O for hours, degrading performance precisely during an incident.

Resiliency modes and how each rebuilds

Three settings matter: Simple, Two-way mirror, and Parity. Simple is striping with no redundancy — fast and useless as protection. Two-way mirror keeps two copies and survives one loss. Three-way mirror survives two but costs two-thirds of raw capacity; on a VPS it rarely pays, since the disks sit on the same provider array anyway.

Parity is the trap. Capacity efficiency looks attractive, but parity spaces are tuned for archival and sequential work, and random writes are punishing. Rebuilds are slow and I/O-heavy. For a database or app server, a mirror is the only sensible resilient option; if you need parity’s efficiency, buy a bigger disk.

Rebuild behaviour compared

Resiliency	Raw to usable	Survives	Rebuild behaviour
Simple	1:1	Nothing	No rebuild; a failed disk loses the space with it
Two-way mirror	2:1	One disk	Copies from the surviving disk; hours of elevated I/O, performance degraded during rebuild
Three-way mirror	3:1	Two disks	Rebuilds from remaining copies; highest write cost and capacity overhead
Parity	~n-1	One disk	Slow, compute-heavy rebuild; random-write latency poor throughout
Single NTFS disk (no pool)	1:1	Provider-level only	No guest rebuild; restore from snapshot or backup instead

The trade is explicit: a mirror converts capacity into recovery time. The real question is how long a snapshot restore takes and whether a snapshot is available when you need it. If the answer is “ten minutes and yes”, a single disk plus a tested backup often beats a mirror that halves your space.

ReFS and integrity streams: where they help

ReFS checksums data and metadata, and with integrity streams it can detect and, on a mirror, repair corruption from the good copy. That pairing is the strongest argument for Storage Spaces in a guest, because it addresses what NTFS cannot: silent bit rot or a bad block noticed only when you read the file.

ReFS is not a general NTFS replacement. It does not support boot volumes, NTFS-style compression, EFS or quotas, and some backup and antivirus products handle it differently. It fits Hyper-V VM storage and large archive volumes. For an IIS content root or a small SQL volume, NTFS is simpler. Enable integrity streams per volume, deliberately.

Building a mirrored pool with PowerShell

The GUI works, but PowerShell is reproducible and shows which disks were claimed. Attach the disks first, confirm they are uninitialised, then create pool, virtual disk and volume in sequence. Pass the disks explicitly so the cmdlet cannot claim one you intended for something else.

Get-PhysicalDisk | Select FriendlyName, MediaType, Size, CanPool
$disks = Get-PhysicalDisk -CanPool $true
New-StoragePool -FriendlyName "DataPool" -StorageSubsystemFriendlyName "Windows Storage*" -PhysicalDisks $disks
New-VirtualDisk -StoragePoolFriendlyName "DataPool" -FriendlyName "DataMirror" -ResiliencySettingName Mirror -NumberOfDataCopies 2 -Size 100GB
Get-VirtualDisk -FriendlyName "DataMirror" | Get-Disk | Initialize-Disk -PartitionStyle GPT
Get-VirtualDisk -FriendlyName "DataMirror" | Get-Disk | New-Partition -AssignDriveLetter -UseMaximumSize | Format-Volume -FileSystem NTFS -NewFileSystemLabel "Data"
Get-VirtualDisk | Select FriendlyName, ResiliencySettingName, HealthStatus, OperationalStatus

Note -Size 100GB on a pair of 100 GB disks: two-way mirroring consumes the full 200 GB of raw capacity, so size at roughly half the pool. Fill the pool and you cannot extend it without another disk. Run the last command weekly — HealthStatus finds a failed member before the second one fails.

Which workloads should use which

Use a single NTFS disk for IIS content, build agents, and small databases where the provider snapshots regularly and you have a tested restore. Use mirrored ReFS for large archives, on-server backup targets, Hyper-V VM storage, and anything where corruption would go unnoticed for months. Use a mirrored NTFS volume for databases that must survive a disk loss, accepting the write cost.

The rule of thumb: if provider storage is already redundant and your restore path is fast and tested, in-guest mirroring buys little for a large capacity and I/O penalty. If corruption detection matters more than throughput, ReFS on a mirror beats anything a single volume offers. Compare Windows VPS plans and check the data disk count — a mirror needs two, and budget plans often cap you at one.

Storage Spaces is a trade, not an upgrade: capacity and simplicity for in-guest protection. Measure the restore time you actually have before assuming you need a mirror. If you build one, pair it with ReFS and watch HealthStatus.