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 \u2014 and inside a VM the redundancy story differs from a physical server, because the hypervisor already provides much of it.<\/p>\n\n\n\n
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<\/a> for how disk tier and snapshot policy affect the choice.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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 \u2014 provider redundancy versus in-guest redundancy \u2014 drives everything.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n Three settings matter: Simple, Two-way mirror, and Parity. Simple is striping with no redundancy \u2014 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n Note 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.<\/p>\n\n\n\n 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<\/a> and check the data disk count \u2014 a mirror needs two, and budget plans often cap you at one.<\/p>\n\n\n\nWhat a single data disk actually gives you<\/h2>\n\n\n\n
What Storage Spaces adds, and what it costs<\/h2>\n\n\n\n
Resiliency modes and how each rebuilds<\/h2>\n\n\n\n
Rebuild behaviour compared<\/h2>\n\n\n\n
Resiliency<\/th> Raw to usable<\/th> Survives<\/th> Rebuild behaviour<\/th><\/tr><\/thead> Simple<\/td> 1:1<\/td> Nothing<\/td> No rebuild; a failed disk loses the space with it<\/td><\/tr> Two-way mirror<\/td> 2:1<\/td> One disk<\/td> Copies from the surviving disk; hours of elevated I\/O, performance degraded during rebuild<\/td><\/tr> Three-way mirror<\/td> 3:1<\/td> Two disks<\/td> Rebuilds from remaining copies; highest write cost and capacity overhead<\/td><\/tr> Parity<\/td> ~n-1<\/td> One disk<\/td> Slow, compute-heavy rebuild; random-write latency poor throughout<\/td><\/tr> Single NTFS disk (no pool)<\/td> 1:1<\/td> Provider-level only<\/td> No guest rebuild; restore from snapshot or backup instead<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n ReFS and integrity streams: where they help<\/h2>\n\n\n\n
Building a mirrored pool with PowerShell<\/h2>\n\n\n\n
Get-PhysicalDisk | Select FriendlyName, MediaType, Size, CanPool\n$disks = Get-PhysicalDisk -CanPool $true\nNew-StoragePool -FriendlyName \"DataPool\" -StorageSubsystemFriendlyName \"Windows Storage*\" -PhysicalDisks $disks\nNew-VirtualDisk -StoragePoolFriendlyName \"DataPool\" -FriendlyName \"DataMirror\" -ResiliencySettingName Mirror -NumberOfDataCopies 2 -Size 100GB\nGet-VirtualDisk -FriendlyName \"DataMirror\" | Get-Disk | Initialize-Disk -PartitionStyle GPT\nGet-VirtualDisk -FriendlyName \"DataMirror\" | Get-Disk | New-Partition -AssignDriveLetter -UseMaximumSize | Format-Volume -FileSystem NTFS -NewFileSystemLabel \"Data\"\nGet-VirtualDisk | Select FriendlyName, ResiliencySettingName, HealthStatus, OperationalStatus<\/code><\/pre>\n\n\n\n-Size 100GB<\/code> 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 \u2014 HealthStatus<\/code> finds a failed member before the second one fails.<\/p>\n\n\n\nWhich workloads should use which<\/h2>\n\n\n\n