trurl

It wasn't the PSU failure in the title that did it, it was using wrong cables on another PSU after the original PSU failed. Actually somewhat similar to the post you linked and there might be some good info there for the OP.

If you used the cable from the old PSU to attach your disk to the new PSU then it seems likely that you fried them. There have been reports of replacing the electronics on the disks to get them working again to recover the data. There is a circuit board on the outside of a disk with the connections on it. It would have to be replaced with the same model.

Did you test them before trusting them in your array? Looks like one of them was run pretty hot at one point and the other took some shocks. Those aren't things I typically look at in the SMART reports and are not attributes monitored by Unraid. I don't know if that might have caused those other SMART attributes or not. Or maybe just bad luck. They should be under warranty so RMA.

If all you want is to move the disks in the case but don't need to change the actual disk (serial number) assigned in the webUI then just move them in the case. Unraid doesn't care, it only looks at the serial number to keep them assigned correctly. I usually use the word "bay" to refer to a location in the case, the word "port" to refer to the connection, and the word "slot" to refer to how they are assigned in Unraid. If you ever take a look at your syslog you will see Unraid listing the assigned disk inventory by their "slot". Now you've done it. You dragged sd'x' into the discussion, which is totally irrelevant and not even guaranteed to be consistent from one boot to the next. It is the md# that corresponds to a specific disk serial number. Also, the very reason you have to rebuild parity2 if you change the disk order is because it must be calculated from the disks themselves in the order they are assigned. If it can be calculated from parity1 alone then how could the order possibly matter? Sorry OP if this has gotten confusing. Just move them to whichever "bay" you want and forget about it. Unraid won't care if you don't change the actual disk (serial number) assigned to each "slot" in the webUI.

Both of those disks have SMART attributes that should be giving you a warning in the SMART status on the Dashboard. Did you tell it to ignore those? So does disk7.

This isn't any clearer I'm afraid. There isn't any way to build parity2 without reading all the data disks. It cannot be derived from parity1.

I don't see anything unusual. I reviewed that thread you linked and the ultimate cause of the problems was the user had put his server in the DMZ and so it was totally exposed to the internet. Not sure about secrets.tdb. I don't have one but some googling seems to indicate it is related to SMB which is the protocol most often used for sharing files on the network. Most of us are using SMB but I'm not sure what would cause secrets.tdb to be created. Probably just some plugin or docker you were using that I don't have. As for super.dat, you do have that in config, as does everyone who has ever started their Unraid array, since it is the file where your disk assignments are stored.

Post another diagnostic

That seems a good plan. Don't even think about caching the initial load, and you might consider waiting until done to assign a parity disk.

I chose Unraid years ago because if its great forum and the community of helpful people here. Just another thing to consider.

You can't start the array after assigning a disk to a new slot? That is sort of what I would expect and seems reasonable to me. Or do you mean it will let you start the array after adding a disk, but then won't let you start it after replacing the emulated disk?

I would retire it since pending is increasing instead of decreasing. A pending sector is one that needs to be reallocated. The drive should be able to reallocate the sector and then the reallocated would increase and pending would decrease. A pending sector can't be reliably read and so could compromise a rebuild since all bits of all disks must be reliably read to reliably rebuild all bits of a missing disk.

Encrypting your data shouldn't be any more difficult than converting filesystems. Rather than point you to that extremely long thread, I'll just summarize the basic idea. Once you get a disk reformatted to encrypted, it can become the destination for moving data off another disk. Then when that disk is empty it can be reformatted as encrypted, and become a destination for more moving. And so on. Many people have done this sort of conversion without ever needing to rebuild parity.

I don't get why this problem was posted to the deprecated and now 3.5 months dead prerelease thread. I assume you couldn't begin the rebuild until Unraid clears the new disk. Just never heard of anyone attempting to do an ADD with a disabled disk in the array, and it never would have occurred to me to even try it. And of course I always discourage this sort of approach: since it is a tremendous amount of disk activity in addition to parity being written on a compromised array. Would have been better just to do the rebuild in my opinion. And since we didn't get a diagnostic maybe nothing wrong with the disabled disk anyway and it could have been used as another source for the data in the event of a rebuild problem. @whitewlf, Moving/copying data from an emulated disk to other disks in the array has to read all the disks to get the emulated data, write destination + parity, then write parity again if it was a move in order to delete the data from the emulated disk.

You can ADD a disk to a new slot with a disabled disk in the array? I guess that would make sense since a clear disk would have no impact on parity.