pmuk

Apparently "no". Just tried doing this and the GUI tells me that the new parity disk isn't correct. I've swapped back in the old parity disk and it appears to be recopying to the new parity disk (~07:45 start/~23:09 end). Definitely "mea culpa" for shutting down rather than leaving it on and completing the published process this morning.

Quick question for those with far more knowledge of the "parity swap" process than I: Step 15 - "Start the array to begin the data rebuild". Could I instead unassign the old parity disk, power down the server, swap the old parity disk out for another larger disk, and then power up the server, (stop the array if it starts up), assign the new larger data disk and finally start the array to rebuild onto the larger disk rather than the former parity disk? Would save a rebuild (resilver?) operation if "yes".

Scratch that, I just refreshed the page and it all looks "correct" now. Must have managed to get a "not entirely correct" copy when I originally looked it up (yesterday/Thursday, I forget exactly when... Been a stupid busy couple of months for me at work)... Mea culpa, I guess.

@JorgeB Sure, this is what I see in Floorp (Firefox fork)

I'm starting this thread to document the process for others whilst I'm doing it. I have an install in a Fractal Design Define S case - three SATA HDDs (3TB at the start - one parity, the other two data) and two cache SATA SSDs (500GB each) - that's all the "drive capacity" the case has. Clearly not massive but it suites my needs (I run a few Docker containers, a Linux VM for day-to-day email/YouTube watching, and disk space for local digital media and the like). I've come into possession of some 8TB Seagate Ironwolf disks; work are downsizing and we WEEEd a couple of 8-bay Synology NAS units we'd been using, so I offered to take four of the disks to save them from crushing. I figure the change of "format" will be sufficient for any data on the disks to be sufficiently safe from recovery. I followed the "parity swap" documentation to upgrade the parity disk first [https://docs.unraid.net/unraid-os/using-unraid-to/manage-storage/array/replacing-disks-in-array/#parity-swap]. The parity copy started 08:08 GMT and completed at 23:26 GMT same day (~15 hours 18 minutes). [And because I'm an idiot, I had to rerun the parity swap process. FOLLOW THE COMPLETE PARITY SWAP STEPS AS PUBLISHED WITHOUT DEVIATION AND YOU'LL ONLY HAVE TO DO IT THE ONCE!] Note: I copied the parity swap steps down as an aide memoire (in case anything bad happens with my Internet connection while the swap is on-going). As @JorgeB has pointed out, the entirety of the parity swap process needs to be completed without interruption or you'll just end up having to carry it out a second time. I started the first data drive swap the following day. The initial "old parity to data drive" ran overnight (~23:15 GMT to ~06:15 GMT), and everything completed fine. When I saw this (~07:30 GMT), I immediately shut down the server and swapped the "old parity" data disk for one of the new 8TB disks as this disk was showing "pre-fail" and "old disk" on a number of its SMART data points. The rebuild on that ran from 07:41 GMT to 23:10 GMT. The second (and for this operation final) 8TB data drive swap began at 07:41 GMT and finished at 19:50 GMT. With that, the data array was fully migrated to new (to me) 8TB disks and I have a whole 10TB of disk space to play with. Next stop: swapping my SATA SSD cache over to being an NVME SSD cache.