trurl

It does count. You could also partition your cache pool so it has a boot partition. That would also mirror the boot partition. But you would have to reformat cache in the process so there is some work to do to get its data moved. I just finished doing that myself using another pool I had setup. Took several hours to complete since I had to move everything (appdata, etc) off the pool so it could be repartitioned and formatted and then move everything back. I have an unlimited license but no way to add another drive to my small form factor build. 7.3 stable was released before you made your post, so no good reason to install the rc at this point.

From the first post in that thread: Is it creating a diagnostics.zip in the log folder of flash?

Here is a post I made explaining how Unraid decides if there has been an unclean shutdown: https://forums.unraid.net/topic/69868-dealing-with-unclean-shutdowns/page/5/#findComment-1087704 Also, that whole thread is pinned near the top of General Support and the first page might be worth reading. https://forums.unraid.net/topic/69868-dealing-with-unclean-shutdowns/

Try logging in to Unraid.net

Please delete your thread.

Does your license allow the extra drive?

Settings for each container install (from Add/Edit/Update Container page) are in its template on flash at config/plugins/dockerMan/templates-user Settings and other working data for each container application are in its appdata. If you have those, you can recreate your containers. https://docs.unraid.net/unraid-os/troubleshooting/common-issues/docker-troubleshooting/

The current syslog is after reboot. Post new diagnostics

That looks like a clean shutdown. Was it?

Parity swap was not involved in this scenario. It is for upsizing parity when you already have a disabled data disk, so you can use a larger disk to upsize parity and use the original parity to rebuild the data disk. Parity swap copies parity to the new parity disk, so the array has to be offline during the copy so parity can't change. Then the array can be online again for the data disk rebuild to the original parity. Also, reviewing the thread. Not clear whether you were considering rebuilding an XFS V4 disk. Of course, that rebuild would have resulted in an XFS V4 disk.

Not clear how you ended up with emulated disk17 as 28TB. It is mounted because the emulated disk is an empty XFS filesystem, since you formatted it. "Format" means "write an empty filesystem to this disk". That is what it has always meant on any OS you have ever used. "Mounted" means the OS has loaded its filesystem to allow its contents to be accessed for read/write. You can write folders and files to that emulated empty XFS filesystem, and those files would be on the disk if you rebuilt it. But whatever was there before was lost when you formatted. The original physical disk, if readable, should still have whatever was on it when you removed it, assuming you didn't do anything else to it. If it was unmountable at that time, maybe it could be repaired with check filesystem and some or all files could be recovered that way. Since you have dual parity and only one emulated disk, you still have some redundancy. If you have an external USB enclosure we could work with it as an Unassigned Device.

If the emulated drive is unmountable, rebuilding from parity will result in an unmountable disk. That is why we always try check filesystem to fix the unmountable filesystem before rebuilding. If you format a disk in the array, whether emulated or not, rebuilding from parity will result in a formatted disk. That is why there are warnings about formatting a disk. Diagnostics shows emulated disk17 is mounted. It has a relatively small amount of used space, probably just filesystem overhead, since you formatted it. Disk19 is not emulated, but it also has little used, so probably also empty. Looks like it was added later. I don't see the original disk17 in your SMART reports. Is it still attached? Maybe we could to something with it beside attempt rebuild.

contact support

That share is set to not use cache, but all its files are on cache. Just making the setting to not use cache will not move anything. And mover won't move it because there is no Mover action because there is no Secondary. You should never set both Include and Exclude (maybe recent versions won't even let you). Include means Only the listed disk(s), so all others are already excluded. Exclude means Except for the listed disk(s), so all others are already included. There is no good reason to think you should set both of these, and possible inconsistencies could result.

Maybe something here for you:

Setup syslog server

Whichever disk you use you will have to rebuild it. And you can't rebuild to the original if it is smaller.

Exactly this many lines in syslog with read errors for disk0 (parity). Since you have parity2 rebuild didn't need parity. SMART attributes for parity look OK, but syslog said critical medium error. Do Extended SMART self-test on parity.

Unraid reads all other disks and uses the parity algorithm to calculate the data for the rebuilding disk.

Can you return disk3 and get a good disk?

The errors during rebuild of disk2 are because disk3 isn't a good disk. It has 81 pending sectors.

root@unSERVER:~# which diagnostics /usr/local/sbin/diagnostics root@unSERVER:~# So diagnostics command is definitely there unless you somehow did something to the OS files.

Looks like it successfully rebuilt disk2 despite all the pending sectors on new disk3. I assume disk3 was the other drive you replaced. You should return it and get a good drive. All drives mounted and showing plenty of contents.

What version of Unraid do you have. This should definitely work unless your version is many years old or there is something wrong with your installation. Do you have a current flash backup?