I have a 4TB drive that failed and am trying to replace it with a new one. My array has one 4tb parity drive(sdc), one healthy 4tb data drive(sdd), the failed drive(sde, which has been replaced with a new one). Where I went wrong was trusting AI to walk me through my situation. I had added a spare 2TB drive to the machine but when I was testing it there were smart errors and so I then removed it. The 4tb drive started to fail catastrophically once the 2tb drive was removed. Chatgpt told me to select "new config" and retain drive assignments, but I'm worried I have now ruined my chance at avoiding data loss on that failed drive. I checked the parity-checks.log in my flash backup download and it stated the last parity check was Sep 1 and was a non correcting parity check. This was before I had added the 2TB drive that had smart errors, and I believe I had not added it to the array. I tried to use ddrescue on the failed drive but only a very small percent of the data was recoverable.

The array would not come online with the failed drive, and I have not started it since selecting "new config" and have given up trying to ask AI for help. Any help would be greatly appreciated on what my next steps should be, or any further information about my setup may be required to assist in troubleshooting.

Do you still have the 2TB? Possibly it was part of the array and would be required to rebuild the 4TB.

Attach Diagnostics ZIP to your NEXT post in this thread.

I do still have the 2tb drive. No data was ever transferred to it, and I don't know if it was ever added to the array. I have attached the Diagnostics zip file as well, taken just now without the 2TB drive installed. Thank you!!

reclaimer-diagnostics-20250929-1332.zip

New Config was definitely the wrong thing to do if you wanted to rebuild a data drive. The only thing New Config will let you build is parity based on the newly (or reassigned) disks.

It looks like you may not have started the array yet though, so it might be possible to make Unraid skip parity build so we can try to rebuild a data disk.

Nothing in your diagnostics tells us anything that happened before you did New Config though. It is crucial to know whether or not the 2TB disk was part of the array.

Do you have any diagnostics or syslogs from before you did New Config?

Do you have another copy of anything important and irreplaceable? Parity is not a substitute for backups. Plenty of ways to lose data besides a failed disk, including user error.

Yeah, I got a little overconfident and trusting of what the AI's were telling me instead of coming here first. It's definitely my fault and a painful lesson to learn! Some of the files were backed up to cloud services, but some I don't have other backups for yet. I am in the process of putting together a second NAS for offsite backup of this one, but haven't completed it yet. Live and learn....

I do have diagnostics from before I hit new config. One dated September 22nd and the other September 2nd. I've attached both. Thanks so much for your help with this!

reclaimer-diagnostics-20250922-1219.zip reclaimer-diagnostics-20250902-2222.zip

Diags from the 22nd also are after a new config, is this when you did it or is it a different one?

Diags from the 2nd show only parity and 4TB disks 1 and 2, there's no 2TB disk on the array, unless it was added later.

Digging through my chatgpt logs I can see I posted a smart report from the failing 4TB drive that was taken on September 2nd, so I must have removed the 2TB drive prior because it was when I turned on the system after removing the 2TB drive the harddrive erros began and the array would not start.

Thanks again!

If the 2TB disk was never part of the array, you can try this, and it won't make things any worse, so it's worth a try:

-IMPORTANT - Check both "parity is already valid" and "maintenance mode" and start the array (note that the GUI will still show that data on parity disk(s) will be overwritten, this is normal as it doesn't account for the checkbox, but it won't be as long as it's checked)

-Stop array

-Unassign the disk you want to rebuild

-Start array (in normal mode now), and post new diagnostics

1 hour ago, JorgeB said:

If the 2TB disk was never part of the array, you can try this, and it won't make things any worse, so it's worth a try:

-IMPORTANT - Check both "parity is already valid" and "maintenance mode" and start the array (note that the GUI will still show that data on parity disk(s) will be overwritten, this is normal as it doesn't account for the checkbox, but it won't be as long as it's checked)

-Stop array

-Unassign the disk you want to rebuild

-Start array (in normal mode now), and post new diagnostics

Just to confirm, should I have the failed 4tb disk installed or the replacement for this procedure?

For now it doesn't really matter, but best to use the replacement (new) disk; if the results are good, you can start the rebuild immediately after.

Here's the fresh diagnostics after starting in maintenance, with parity already valid checked. then stopping, unassigning the drive and starting again.

Thanks again. I'm curious what you're looking for in the diagnostics. I'd love to learn more about this stuff!

reclaimer-diagnostics-20250930-1533.zip

Emulated disk2 is unmountable. That might mean it has filesystem corruption, or it might mean it can't be emulated because the 2TB disk is missing from the array.

Check filesystem on emulated disk2 from the webUI and post the output.

Do you know if disk2 was XFS? Do you use encryption?

There's no filesystem signature being detected on the emulated disk 2, suggesting parity wasn't valid with that config, with the array started post the output from blkid /dev/md2p1

I'm fairly certain I was using xfs, as disk1 is also an xfs disk and I wanted them to be the same, but i could be mistaken and was using zfs.

On 10/1/2025 at 8:26 AM, JorgeB said:

There's no filesystem signature being detected on the emulated disk 2, suggesting parity wasn't valid with that config, with the array started post the output from blkid /dev/md2p1

@trurl I cannot seem to find a way to check filesystem in the webUI based on the instructions you linked, I'll keep trying but as of now, nothing is showing me a way to check it.

Edited October 3, 2025Oct 3 by 0xjroc

On 10/1/2025 at 10:26 AM, JorgeB said:

with the array started post the output from blkid /dev/md2p1

18 minutes ago, trurl said:

  On 10/1/2025 at 8:26 AM, JorgeB said:

with the array started post the output from blkid /dev/md2p1

nothing shows up in the terminal with that command, but it exists...

Edited October 3, 2025Oct 3 by 0xjroc

And output of wipefs /dev/md2p1

Just in case there are multiple sigs, and note that the command as written won't wipe anything.

3 minutes ago, JorgeB said:

And output of wipefs /dev/md2p1

Just in case there are multiple sigs, and note that the command as written won't wipe anything.

same thing as blkid, returns to console without any output

The disk was not formatted or is not being correctly emulated, assuming the latter, it suggests parity is not totally valid. Try running xfs_repair on it, in case it can find a backup superblock:

xfs_repair /dev/md2p1

Just now, JorgeB said:

The disk was not formatted or is not being correctly emulated, assuming the latter, it suggests parity is not totally valid. Try running xfs_repair on it, in case it can find a backup superblock:

xfs_repair /dev/md2p1

It's printed about 100 lines of ..... after saying "Phase 1 - find and verify superblock...

bad primary superblock - bad magic number !!!"

Any use installing the removed 2TB drive and trying again?

Edited October 3, 2025Oct 3 by 0xjroc

It can take some time while looking for a backup superblock.

24 minutes ago, JorgeB said:

It can take some time while looking for a backup superblock.

it completed, output of blkid /dev/md2p1 is:

/dev/md2p1: UUID="31b5f662-7d37-43fa-93ee-b65c20e8bb92" BLOCK_SIZE="512" TYPE="xfs"

Restart the array and post new diags.