Hello @Jan
I would not remove, initialize, reset, or retire the failing disk yet.
The most important detail in your description is this: “the pool became Primordial and there is no virtual disk in the pool.”
In Storage Spaces, Primordial isn't the name/state an existing user-created storage pool normally changes into. The primordial pool represents physical disks that are available to the storage subsystem. A normal Storage Spaces pool should appear separately with:
IsPrimordial = False
Microsoft's Storage Spaces documentation shows this distinction explicitly.
So before replacing the disk, we need to determine whether Windows still recognizes the original Storage Spaces metadata after the motherboard/SATA-controller change.
Please open PowerShell as Administrator and post the output of:
Get-StoragePool | Format-Table FriendlyName, IsPrimordial, OperationalStatus, HealthStatus, IsReadOnly, Size, AllocatedSize -AutoSize
Then:
Get-PhysicalDisk | Format-Table FriendlyName, SerialNumber, CanPool, OperationalStatus, HealthStatus, Usage, Size -AutoSize
and:
Get-VirtualDisk | Format-Table FriendlyName, ResiliencySettingName, OperationalStatus, HealthStatus, Size -AutoSize
Also run:
Get-Disk | Format-Table FriendlyName, SerialNumber, OperationalStatus, PartitionSize, Size -AutoSize
and:
Get-StorageJob
Please post those results before making further changes.
Don't recreate the pool
In particular, don't run:
New-StoragePool
and don't initialize or format any of the four disks.
Microsoft warns that incorrect removal/manipulation of disks belonging to a Storage Spaces pool can leave the pool or disks unusable.
The fact that you could initially access your files after changing the motherboard is encouraging, because Windows was apparently able to recognize the Storage Spaces configuration at that point.
The PCIe-to-SATA controller change is also significant. Make sure all four original physical disks are simultaneously visible to Windows, with the expected capacities and serial numbers. A missing/inaccessible member disk or controller/driver problem can change what Storage Spaces is able to assemble.
Whether the failing disk can safely be replaced depends on resiliency
You mentioned that you don't remember whether the space was “spanned or striped.”
That's critical.
If:
ResiliencySettingName = Simple
then the data is striped without resiliency. Losing one physical disk can mean losing data from the entire virtual disk.
If it reports "Mirror or Parity", then Storage Spaces may be able to reconstruct the data, assuming enough healthy members remain.
That's why I wouldn't issue: Set-PhysicalDisk -Usage Retired yet.
If the original pool and virtual disk are still recognized
If the output eventually shows something like:
StoragePool:
NASPool IsPrimordial=False
VirtualDisk:
NASData ResiliencySettingName=Mirror
then Microsoft's documented procedure for replacing a failing disk in a standalone Storage Spaces pool is essentially:
Set-PhysicalDisk -UniqueId "<failing-disk-ID>" -Usage Retired
then repair the affected virtual disk:
Repair-VirtualDisk -FriendlyName "<virtual-disk-name>"
monitor the repair:
Get-StorageJob
and only after the repair completes and the retired disk has no remaining virtual-disk footprint, remove it from the pool:
$disk = Get-PhysicalDisk -UniqueId "<failing-disk-ID>"
Remove-PhysicalDisk -PhysicalDisks $disk -StoragePoolFriendlyName "<pool-name>"
Microsoft's current standalone Storage Spaces guidance documents this retire → repair → verify → remove sequence.
Microsoft also recommends adding a replacement disk before removing the failing disk when the pool doesn't have sufficient free capacity to tolerate removal.
But I would not execute that procedure until your pool and virtual disk are actually visible again.
Back up what you can right now
Since the disk is already failing, if the volume is currently accessible, I'd prioritize copying irreplaceable data to storage outside this pool before attempting a repair.
Repair operations put significant I/O load on the remaining disks. If this turns out to be a Simple/striped space, or another disk fails during reconstruction, your options become much more limited.
If the data is important and the virtual disk has completely disappeared, I'd stop making configuration changes and consider imaging the failing drive before continuing.
What I'd like to see next
Please post the output of these four commands:
Get-StoragePool
Get-VirtualDisk
Get-PhysicalDisk
Get-Disk
The two most important things we need to establish are:
Does Windows still see a non-primordial storage pool, and what was the virtual disk's ResiliencySettingName?
Once we know that, we can determine whether the failing disk can safely be retired/replaced or whether this needs to be approached as data recovery rather than a normal Storage Spaces disk replacement.
Please "Accept the Answer" if this information helped you. This will help us and others in the community as well.