Australian cloud for business software — built and run in Sydney since 2003

NetLeverage
NetLeverage

Storage Spaces on a standalone server: a mirror is not a backup, and the pool states tell you which problem you have

Technical article
Backup & Recovery

About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.

Plenty of small and mid-sized organisations run a physical Windows server whose data volume sits on Storage Spaces. It is built into Windows, it needs no RAID card, and it lets a server keep working when a drive dies. Microsoft describes it as a way to aggregate multiple physical drives into a single logical storage pool, from which you carve virtual disks with the resiliency you choose.

Two misunderstandings tend to follow it into production. The first is that a mirrored space is a backup. The second is that every warning on a pool means the same thing. This article deals with both. It covers standalone Storage Spaces on one server. Storage Spaces Direct, the clustered version, shares some of the same health states but has its own design rules, and we mention it only where Microsoft's pages apply to both.

What each layout protects against

Microsoft's Storage Spaces overview describes three resiliency types.

Simple spaces stripe data across drives with no redundancy. Microsoft is direct about the consequence: no fault tolerance; a single drive failure results in data loss. Its deployment guide adds: Don't use to host irreplaceable data.

Mirror spaces keep two or three copies. According to the overview, two-way mirroring tolerates one drive failure; three-way mirroring tolerates two simultaneous drive failures. The price is capacity: Microsoft gives 50 per cent overhead for two-way and about 66 per cent for three-way.

Parity spaces store parity information so that data can be rebuilt after one drive fails (single parity) or two (dual parity). Microsoft says parity uses capacity more efficiently but has lower write performance, and lists it as suited to archival storage and backups.

Microsoft’s standalone Server deployment guide requires at least two physical disks for a mirror that survives one disk failure, at least five for a mirror that survives two simultaneous failures, and at least three for single parity. These are the server guide’s minimums; confirm the selected layout and deployment requirements.

The Windows client help page gives the drive counts a home user or small office meets first: Storage Spaces needs at least two extra drives besides the Windows drive, and parity needs at least three drives to survive one failure and at least seven to survive two.

Every one of these protections is about drives. None of them is about data.

Why a mirror is not a backup

A mirror writes each change to every copy at once. That is what makes it survive a drive failure, and it is also why it cannot help in the other cases a backup exists for. In our reading, a mirror copies these just as faithfully as it copies good data:

  • a user or administrator deleting a folder
  • an application writing corrupt data
  • ransomware encrypting the volume
  • a mistaken format or partition change

There is a single pool, in a single server, in a single room. Theft, fire, flood, a failed power supply that damages several drives, or a controller fault that affects all of them are outside what drive redundancy can address. Microsoft's own wording points the same way. For a virtual disk that has lost too many drives, its recommended action is Replace failed drives and then restore your data from backup. Microsoft assumes the backup exists.

Our recommendation is to treat Storage Spaces resiliency as the thing that keeps the server running through a drive failure, and to keep a separate backup of the data on that pool, stored away from the server, with a restore that has been tested.

Hardware choices that affect recovery later

Several requirements on Microsoft's standalone deployment page matter after a failure, not just at setup time.

  • No RAID underneath. Microsoft recommends simple host bus adapters without RAID functionality. If an adapter can do RAID, it must be in non-RAID mode with all RAID functionality disabled. Adapters must not abstract the physical disks, cache data or hide attached devices, and Microsoft says Storage Spaces is compatible only with adapters where RAID can be completely disabled. In our view, a pool built on drives a RAID controller has hidden means two layers of redundancy that do not know about each other, which is a hard position to recover from.
  • iSCSI and Fibre Channel. Storage Spaces is supported on these only when the virtual disks on them are nonresilient (simple).
  • USB. USB drives can be used, but Microsoft says it is not optimal to use USB drives in a server environment. The Windows client page explains one reason: many USB enclosures and hubs add an abstraction layer that makes Windows treat drives as removable or hides individual disks.
  • Hot spares. The deployment guide shows how to designate one or more drives as hot spares when creating the pool. A spare is a drive already in place for the pool to use when another one fails.
  • Unplanned shutdown. For mirror spaces, Microsoft notes that dirty region tracking records changes so that, after an unplanned shutdown, the drives are made consistent with each other again. For parity spaces, the guide separately says journaling helps prevent data corruption.

If you inherit a server, our recommendation is to find out which of these apply before a drive fails: what adapter the drives sit behind, whether any are on USB, whether there is a spare, and which layout each virtual disk uses. That last point matters because a server can hold a mirror and a simple space in the same pool, and only one of them survives a drive failure.

Reading the states: wait, reconnect, repair or restore

When something goes wrong, Storage Spaces reports a health status and one or more operational states for the pool, for each virtual disk and for each drive. Microsoft's health and operational states page lists them with an action for each. It applies to both Storage Spaces and Storage Spaces Direct. The states fall into a few groups, and in our reading the group tells you what kind of day you are having.

The pool has gone read-only

A pool in the Unknown or Unhealthy state is read-only and can't be modified until it returns to Warning or OK. Microsoft gives two common reasons.

  • Incomplete: the pool has lost its quorum, meaning most drives in the pool have failed or are offline. Storage Spaces sets the pool to read-only until enough drives are available again. Microsoft's first action is to reconnect any missing drives.
  • Policy: an administrator set the pool to read-only.

The read-only state is protective. In our view, the first job is to find out why drives are missing (a loose cable, a failed enclosure or backplane, a powered-off shelf) rather than to force anything.

The virtual disk is working, but with less protection

A virtual disk in the Warning state is still serving data. Three of its operational states matter here.

  • Degraded means resilience is reduced because one or more drives failed or are missing, and there are outdated copies of your data on these drives.
  • Incomplete (in the Warning state) means resilience is reduced because one or more drives failed or are missing, but the missing drives contain up-to-date copies of your data. Microsoft's action is to reconnect missing drives and replace failed ones.
  • In service means Windows is repairing the virtual disk, for example after a drive was added or removed. Microsoft says it should return to OK when the repair is complete.

Our reading is that this is the window in which a second failure becomes dangerous, especially on a two-way mirror or single parity space that can only absorb one. It is a good moment to confirm the latest backup completed before starting a long repair.

The virtual disk has lost data

An Unhealthy virtual disk means some or all of the data on the virtual disk is currently inaccessible. The state Microsoft calls No redundancy means the virtual disk has lost data because too many drives failed. The documented action is to replace the failed drives and restore from backup.

This is the case the whole article is about. No repair of the pool brings back data it no longer holds.

The virtual disk is detached

A virtual disk can also show Unknown (in PowerShell) or Information (in the Control Panel item) because it is detached or offline. Microsoft lists several reasons:

  • By Policy: an administrator took it offline, or set it to require manual attachment, in which case it must be attached again after every restart. Microsoft documents how to bring it back online and how to turn automatic attachment back on.
  • Majority Disks Unhealthy: too many of its drives failed, are missing, or have stale data. The first action is to reconnect missing drives.
  • Incomplete: not enough drives are present to read it.
  • Timeout: attaching it took too long. Microsoft says this shouldn't happen often and may pass in time.

In our reading, "By Policy" is usually a configuration surprise rather than a failure, for example after a restart, and is worth checking before anyone assumes the worst.

A drive's own state

Each physical drive also reports states. Two are worth knowing.

  • Lost communication: the drive is missing. Microsoft's action is to reconnect it, replace it, or collect diagnostics.
  • Split: the drive has become separated from the pool. Microsoft's documented fix resets the drive, erasing all data from it, and adds it back as an empty drive before repairing the virtual disk.

Our recommendation is to treat any action that erases a drive as a decision, not a step. Before taking it, confirm which virtual disks still have a healthy copy of everything elsewhere in the pool, and confirm the backup. If that cannot be confirmed, stop and get help rather than continue.

Replacing and removing drives

The Windows client page warns that upgraded pools are not compatible with previous Windows versions. Do not assume an older recovery system can import an upgraded pool; confirm the supported destination before making any pool upgrade.

On upgraded or newer pools, the Windows client help page describes Prepare for removal: Windows copies the data on that drive to the other drives in the pool, which could take several hours, and then lists the drive as ready to remove. If preparation fails, Microsoft says the usual cause is too little free space in the pool, and suggests adding a drive as large as the one being removed first.

Our reading of that guidance has a planning consequence. A pool that is nearly full has less room to move data off a failing drive, so free capacity is part of your recovery plan, not just your growth plan.

A short checklist for a server with Storage Spaces

These are our recommendations, drawn from the documented behaviour above.

  1. List every virtual disk and its layout. Know which are simple spaces and what lives on them.
  2. Confirm the backup covers the data on the pool, is stored away from the server, and has been restored at least once in a test.
  3. Check the hardware path. No RAID abstraction, no USB enclosures hiding drives in a server role.
  4. Decide on a spare and keep a replacement drive of the right size on hand.
  5. Keep free space in the pool so a drive can be prepared for removal.
  6. Watch the health status and treat a Warning on a resilient disk as urgent, because it means the next failure may cost data.
  7. Write down the "stop" point. Any step that erases a drive or forces a pool online waits until the backup is confirmed.

Use the procedure for the installed server version

The Windows client Storage Spaces page is useful for understanding capacity and drive replacement, but its Settings screens and “Prepare for removal” workflow are not instructions for Windows Server. For a standalone server, use the server deployment and health-state documentation for the installed version. Keep Storage Spaces Direct procedures separate; a standalone pool has no second server to supply data merely because the same health page also discusses clustered systems.

Before any drive operation, the recovery record should identify the physical drive by more than its bay position, the affected virtual disks, their resiliency and which remaining copies are current. Available free space alone does not prove the pool can repair the layout. If the health state indicates data has already been lost, a replacement drive cannot recreate missing content by itself. Establish the usable backup and destination capacity before anyone resets, removes or repurposes a drive.

Risks and limits of this article

  • It covers standalone Storage Spaces. Storage Spaces Direct has different hardware and fault-domain rules, and Microsoft documents those separately.
  • States and actions are quoted from Microsoft's documentation as it read on 11 November 2026. Behaviour can differ between Windows versions and pool versions.
  • Nothing in this article was tested on hardware, and no steps were carried out for it.
  • It does not cover hardware RAID, third-party storage software or file-system repair.

Sources

Writer research: 11 November 2026. Independently reopened for review: 13 November 2026.