Server 2019 Storage Pool（3 columns, 2 copies）异常行为排查咨询

Hey there, let's break down your two Storage Spaces issues one by one—this is a great deep dive into how the underlying logic works!

第一个问题：3块盘丢失后存储池直接故障而非降级 #

Your initial expectation makes total sense on paper: with a 3-column, 2-copy setup, losing one disk per column should leave every piece of data with its duplicate intact. But the pool going faulted instead of degraded boils down to Storage Spaces' quorum (arbitration) mechanism.

By default, Storage Spaces requires a majority of the pool's disks to be online to bring the pool up—this is a safeguard against split-brain scenarios (like when multiple controllers each claim ownership of the pool in a multi-enclosure setup). For your 6-disk pool, the quorum threshold is 4 disks (more than half). When you lost 3, only 3 remained—exactly below that threshold. Even though your data was theoretically intact, the pool shut down to prevent potential conflicts or data corruption.

You can verify this with a couple of PowerShell commands:

# Check fault domain awareness and required fault domains
Get-StoragePool | Select-Object FriendlyName, OperationalStatus, FaultDomainAwarenessDefault, RequiredNumberOfFaultDomains

第二个问题：故障盘自动退役，新盘闲置但虚拟盘显示健康 #

First, the automatic retirement of the failed disk is normal—it's a default Storage Spaces behavior. If a disk loses communication for a sustained period (usually minutes to hours), the system marks it as retired to stop wasting resources waiting for it to come back. You can confirm this setting with:

Get-StoragePool | Select-Object FriendlyName, AutoRetirePhysicalDisks

Now, the weird part: the new disk sitting idle while the virtual disk shows healthy. Here's what's likely happening:
Your 3-column, 2-copy virtual disk only needs one disk per column to stay functional (since each column has a duplicate). When one disk failed, the remaining disk in its column still held all the data for that segment—so the virtual disk never needed to "repair" anything. When you added the new disk, Storage Spaces didn't automatically slot it into the empty spot in the column because the virtual disk was already in a healthy state.

To get the new disk integrated and restore the full 2-copy redundancy for all columns, you need to manually trigger a repair:

# Replace "YourVirtualDiskName" with your actual virtual disk name
Repair-VirtualDisk -FriendlyName "YourVirtualDiskName"

This command will force Storage Spaces to rebuild the missing duplicate onto the new disk, balancing the load across all 6 disks again.

备注：内容来源于stack exchange，提问作者dognose