trurl

Not sure what you misinterpreted. This is true, since the bad disk isn't involved at all in rebuilding to a new disk. It is replaced. Less true if multiple disks are known to be bad, since all other disks must be reliably read to reliably rebuild a disk. One of your disks had a lot more reallocated than is safe, and I suspect those had been increasing. Not clear if other disks are of concern or not.

Copy is faster and safer than move. Move is Copy from source to destination, then delete from source. Delete is a write operation, so that would be additional writing to suspect disk even though it is just updating the filesystem to mark the deleted blocks available instead of overwriting all the data. Also all writes update parity. You can exclude the bad disk from user shares so there won't be duplicates, then when all files have been copied elsewhere, you can New Config to remove the disk and rebuild parity.

Probably safer to rebuild to new disks.

Do you have a current flash backup?

Redo then. Save the trial.key file from the config folder on flash, make a new install on the flash, put the trial.key back in the config folder.

Post new diagnostics

Try booting from USB2 port

Still strange. Do you have a current flash backup?

Try again to get diagnostics and attach to your next post.

Did you edit those diagnostics before posting? There is no syslog in them.

The config folder from flash has all of your configuration and is all you need to get your configuration going again on a new install.

Do you have a current flash backup?

You assign the new disk 9 and start the array to begin rebuild. "mount" has a different and specific meaning. Note that emulated disk9 has a lost+found share on it. Those are folders and files that repair couldn't figure out.

Post new diagnostics with the array started in normal mode

I wouldn't count on that having a GUID for license

Setup syslog server. There is a "sticky" thread pinned near the top of this General Support subforum about unclean shutdowns. Here is a post I made to that thread explaining how Unraid decides if a shutdown has been unclean:

Most recent syslog in those diagnostics didn't show those problems. Did you reseat the drives?

SMART reports looked OK for those. All disks on same controller. How are these 2 disks connected to power?

syslogs indicate problems communicating with disks 1,2. Maybe it couldn't sync during shutdown. Any power splitters?

If you unassign the bad disk and start the array, it will be emulated by reading parity and all other disks. You can copy files from the emulated disk to other disks in the array, to Unassigned Devices, or to other computers on the network. If you copy to other disks in the array, performance will be impacted since in addition to writing to an array disk and updating parity, it will also have to read all array disks plus parity to get the emulated data to copy. Lots of seeking involved. Perhaps a better approach would be to mount the new disks as Unassigned Devices and copy the emulated data there. Then you can New Config the new disks with their contents into the array and rebuild parity.

No good reason to do move instead of copy and plenty of good reasons to avoid doing move instead of copy. Move is Copy from Source to Destination, then Delete from Source. Delete is a write operation. Writing to that failing disk is just asking for trouble. And Copy is faster since there is no Delete to be done. Just exclude the bad disk from user shares and copy its folders to the new disks. If a file is unreadable then it won't be copied. If a file is corrupt it might still be copied but I don't see any alternative. Do you have backups or checksums or anything that might tell if a file isn't what it should be?

The only other disk in the array doesn't have enough capacity for the contents of the bad disk anyway. Might be best to shutdown, wait on the new disks and consider how to proceed.

Unrelated, your appdata and domains shares are on the array and configured to be moved to the array. Better if Docker/VM related shares - appdata, domains, system - are all on cache or other pool with nothing on the array, so Docker/VM will perform better and so array disks can spin down since these files are always open. We can work on that later.

Copy is safer and faster than move. Move requires writing to the source disk to delete the source files after they have been copied. You can exclude the source disk from user shares so there won't be duplicates. You are going to have to New Config to get the array assignments without the bad disk and with the new disks. Do you have enough ports to work with the old disk and new disks together?