trurl

You can usually go directly to the correct support thread for your docker by clicking its icon and selecting Support.
 
 

You will have to New Config before it will let you reassign parity 2

You should go to each for your WD disks and add attributes 1, 200 for monitoring. Disk1 has a large number of attribute 1.
 
You should replace disk1 which I assume is what you intended. Do that before adding parity2. Dual parity is probably overkill since you only have 5 data disks.

Doesn't matter at all what is on the disk you are going to rebuild to. It can be a clear drive, it can be a drive formatted as XFS or as anything else. It can even be an NTFS drive from Windows full of pron. Rebuild is going to overwrite the entire disk.
 
Parity doesn't know anything about filesystems and files. It is all just bits.
https://wiki.unraid.net/Manual/Overview#Parity-Protected_Array
 
The bits on a disk represent a filesystem with its files, but parity is just going to rebuild the bits. The rebuilt bits will represent the same filesystem with its files as were on the original disk.
 
That will get the disk to the correct filesystem, but it will be an empty filesystem. So first
Then after reformat you can copy to the empty filesystem.

Doesn't really matter at this point what is assigned as disks 5, 6 since we aren't going to actually try to access those disks for a while
Go to Tools - New Config, Retain All, Apply Might as well assign the new disks as disks 5, 6. You don't really have to, but if you go ahead and assign them now you won't have to later. Don't change any other assignments. Very Important! Check BOTH Parity Valid and Maintenance Mode checkboxes, then start the array. This will accept all disks just as they are without accessing any disk and changing any contents. Then, post a screenshot of Main - Array Devices and new diagnostics.
 

Diagnostics includes the current syslog, which is in RAM like the rest of the OS. Diagnostics can tell us how things are now, but can't tell us anything about what happened before boot.
 
Disk3 has
199 UDMA_CRC_Error_Count -O-R-- 200 200 000 - 1347 These are recorded by the drive when it receives inconsistent data as determined by checksum. These are almost always connection problems. Often these won't cause a problem because the data is resent. And connection problems often don't result in CRC errors since the drive never receives any data to checksum. You should be getting a SMART warning ( 👎) for this disk on the Dashboard page. You can click on it to acknowledge and it will warn again if it increases.
 
Other than that, SMART for disk3 looks OK, and SMART for parity looks OK.
According to SMART reports, parity has had no self-test run. Disk3 did pass some short tests, but that was a couple of years ago. Neither have had extended tests.
 
Unraid disables a disk when a write to it fails for any reason. But the failed write updates parity so it can be recovered by rebuilding. And even though one of the disabled disks is parity, parity2 was updated. So the disks are now out-of-sync with the array and have been "kicked out".
 
After a disk is disabled, it isn't used again until rebuilt. It is instead emulated by parity. Reads from the disk are emulated from the parity calculation by reading all other disks, and writes to the disk are emulated by updating parity so the emulated write can be read. The initial failed write is emulated, and any subsequent writes are emulated, and these can all be recovered by rebuilding. (In your case, the only parity still being read or updated is parity2 since parity is disabled).
 
Bad connections are much more common than bad disks, and that is probably what happened here, but unless you have syslog from before reboot, can't say for sure. No obvious problems currently.
 
Emulated disk3 is mounted and has plenty of data, so that's all good. The emulated contents is what you will get when you rebuild.
 
Your configuration looks good. Most people would consider dual parity overkill since you only have 3 data disks in the array.
 
It's usually safer to rebuild to spares and keep the originals in case of problems, but it should be OK to rebuild onto the same disks after checking all connections.
 

I'm not sure that name is allowed

yes

Not ADD, REPLACE.
 
Preclear if you want to test the new disk. A clear disk is only required for ADD, not for REPLACE. Rebuild will be a test of sorts anyway.
 
Since the new disk is already installed, all you need is...
 
Stop array, assign new disk as disk1, start array to begin rebuild.

There is no complete list of corrupted files.
 
Recreate flash drive as a new install of whatever version, copy the config folder from your backup.

setup syslog server

https://en.wikipedia.org/wiki/Standard_RAID_levels#General_parity_system

Rename or delete config/smb-extra.conf on the flash drive and reboot.

I don't even bother with mover tuning. I have enough cache (only 500G, less than you have) to hold all I write to it in one day, and the cached user shares get moved to the array in the middle of the night.
 
I have a separate pool "fast" (nvme), 256G, where I keep my default shares.
 
Depends on how much you write to cache.
 
When I had simpler needs and simpler hardware, I didn't bother with caching much because most writes were queued downloads or scheduled backups, and nobody was waiting on them to complete anyway.
 
Now, I have downloads that need post-processing, and I have enough hardware that I can download to a cached share, post-process to my "fast" pool, where it gets moved ('arr) to the final destination cached share.
 
Anything you keep permanently on a single disk pool needs backup. CA Backup plugin, for example. In fact, I would say appdata and vdisks need backup even if on a redundant pool.

Maybe you mean the disk was disabled? Or perhaps unmountable? Both? The only way an OS would be on a hard drive is if you have a VM on it.
 
NEVER format a disk that has data you wish to keep. Whether the disk was disabled, unmountable, or whatever.
 
In future, please ask for help before doing anything.

https://wiki.unraid.net/Manual/Storage_Management#Rebuilding_a_drive_onto_itself

Yes 

If Unassigned Devices sees a mountable filesystem on a disk, it will offer to mount it. If not, it will offer to format it so it has a mountable filesystem. Unassigned Devices will mount disks of various filesystems, including NTFS, which is a Windows format.
 
Disks in the Unraid array or pools must be formatted XFS, btrfs, ReiserFS (soon to be deprecated and unsupported so don't use). ZFS is planned for a future release.
 
Default for the array is XFS. Multidisk pools must be btrfs.
 
After you add a data disk to the array you will have to tell Unraid to format it. Same for first disk in pool. Parity has no filesystem so it doesn't get formatted.
 
 

Everything about your configuration is in the config folder on flash. If you use a different flash drive you will have to transfer your license.
https://wiki.unraid.net/Manual/Changing_The_Flash_Device
 
 
Maybe diagnostics when booted with the original flash drive would tell us something.

Sounds like you've got it.
 
If the drives you are removing are empty, New Config with all disks assigned as you wish and rebuild parity. Be sure you don't assign any data disk to any parity slot. After array starts you can format the new disks including reused parity.

What happens when Unraid server is off?
 
What happens if you boot a new install of Unraid? 

Probably you are mistaken that it spent 12 hours formatting the old parity drives. Format doesn't take much time at all.
 
When you ADD disk(s) to new slot(s) in the parity array with valid parity, the new disk(s) must be cleared so parity will remain valid. Clearing the disks is probably what took 12 hours.
 
If they have finished clearing you can format them now. It will take a few minutes at most.