I’m experiencing several issues with my Unraid array.

The array contains 30 devices, of which 5 are currently unassigned. Two 24 TB parity drives.

• Disk22 (24 TB) dropped from the array several days ago and is confirmed faulty. I will RMA this drive.

• Disk17 dropped tonight. Its SMART data is clean, and I’m confident nothing has been written to it since it dropped. I intend to avoid any writes to this disk.

Diagnostices attached.

I do not have a spare 24 TB drive. However, I do have two 28 TB drives that were originally planned to replace the 24 TB parity drives.

Unraid does not allow me to replace disk22 with a 28 TB drive because it exceeds the size of the current parity drives, even though I am willing to leave the extra 4 TB unused until both parity drives are upgraded to 28 TB.

I want to replace disk22 and upgrade both parity drives to 28 TB.

I canceled the rebuild of disk17, as I believe it is unnecessary.

My plan is:

1. Copy the contents of disk22 to a ZFS pool (estimated ~1 week).

2. Perform New Config, preserving all assignments.

3. Replace both parity drives with 28 TB disks.

4. Assign one of the former parity drives as the replacement for disk22.

5. Start the array.

6. Copy data from the ZFS pool back to the new disk22.

Steps 5 and 6 may be slow if run concurrently, so I may wait until the parity build completes before starting step 6.

This process may take up to three weeks to complete.

Any suggestions for a safer, faster, or cleaner approach?

juno-diagnostics-20260114-0905.zip

37 minutes ago, Gico said:

Unraid does not allow me to replace disk22 with a 28 TB drive because it exceeds the size of the current parity drives,

You can use the parity swap procedure for that.

Thank you. I was aware that the parity swap option exists, but I assumed that a fully valid parity and healthy array disks were required in order to use it.

However, this procedure implies that:

• The array would be unavailable during the copy phase (approximately 4–5 days), which is a significant drawback for me.

• As I understand it, the data would be rebuilt with only one parity drive replaced initially. I would then need to replace the second parity drive as well, which would trigger another parity build.

• Even if it were possible to replace the second parity drive and perform the copy simultaneously or sequentially, the array would still remain unavailable for an extended period.

Overall, this approach does not appear to save much time compared to my original plan.