itimpi

Just acknowledge.  This is a connection error (frequently caused by SATA cabling or power) rather than a drive error and triggers a retry so as such just slows things down unless you gets lots of them.  Occasional ones are not something to worry about but if they occur frequently check the cabling.  Note it never resets to 0 so all you can do is stop it increasing.

This is referring to avoid doing a disk path to a /mnt/user/sharename type path.

are you sure parity is currently valid which is required if you are going to tick the Parity is Valid after using New Config.
 
Your process is OK, except for the fact there is no Parity is Valid option as that is only relevant if going via New Config which would not be the case for step 6.
 

You could either umount the image you have just mounted or perhaps even simpler to just reboot your server.

You need to run without -n or no repair will be done, and if it ask for it add -L.

Almost sounds as if the 'Config' folder was not copied across from the backup as that contains all your settings (and licence key).

Unfortunately not.   Existing files are modified in place.

I would suggest removing the Mover Tuning plugin and then try running mover again with docker and VM services disabled,   That plugin has been known to sometimes interfer with regular Mover behaviour.
 
If that gets the files off the 'cache' pool you can afterwards change the share settings for new files to go directly to the array.
 
Ideally that will also get all of the 'system' share onto the cache to maximise performance and that share can then be set to cache only.

Did you remember to either put your server’s address into the Remote Server field or set the mirror to flash option?   You need to have set one of those to get anything recorded as otherwise you are just listening for messages from other servers.

You can get those sorts of errors from cabling issues (SATA or power) so the disk might be OK.  

You need to copy data elsewhere; stop array; set disk to be encrypted; start array;  format; and then copy back any data if needed.   No need to use pre-clear or anything like that. And no parity rebuild would be required as parity is maintained across the steps I mentioned.
 
you might also want to set the default format under Settings->Disk Settings to be encrypted so this situation does not happen again next time you add a drive.

You could delete the one that has the oldest modification date as that would be the one not currently being used.

You have that share set to "Manual" Split Level so this means you have to create the top level folder before it will start using the other drive.   You may want to also create the next level to control where the next level is allowed to go.

You can do it under Settings->Docker if the docker service is set to disabled.

That would be expected if you are using the default write mode.
 
You might want to read up on the write modes here in the online documentation accessible via the Manual link at the bottom of the Unraid GUI.  In addition every forum page has a DOCS link at the top and a Documentation link at the bottom.  

No.  1 parity drive provides tolerance against any 1 data drive failing.   The available space is the sum of the data drives (which do not need to all be the same size).
 
You might find it useful to read about how parity works as described here in the online documentation accessible via the Manual link at the bottom of the Unraid GUI.  In addition every forum page has a DOCS link at the top and a Documentation link at the bottom.   The Unraid OS->Manual section covers most aspects of the current Unraid release.

No.   Btrfs allows for drives of unequal sizes to be used in a redundant manner..  However in the case you mentioned with only 2 drives there would only have been 1TB of usable space despite the GUI suggesting otherwise.

It does.   This suggests something got corrupted on the flash drive.

Can you copy the 'config' folder from the flash drive?   That has all your settings and licence key.

That sounds as if your BIOS is no longer trying to boot from the flash drive!  Have you checked that it is still set to do so?

It needs to go into the ‘config’ folder on the flash drive.

The BTRFS errors are coming from the loop2 device which is where you docker image is mounted (by default this is formatted as BTRFS internally).   It is not clear why this is happening.
 
Since it looks like the docker.img file may well be corrupt, I suggest that you recreate the docker.img file and then reload your containers with settings intact via Apps->Previous apps.

I assume you will be adding the other ‘cache’ drive as a new pool?   Assuming that is the case it is completely independent of the changes to the main array.
 
are you adding the old parity drive as a new data drive (or is it replacing an existing drive?
 
if it is going to replace an existing array data drive then the parity swap procedure should be used.
 
if it is going to be a new drive then you should first upgrade the parity drive:
- stop array
- unassign old parity drive
- assign replacement parity drive 
- start array to rebuild parity based on the current data drives..  keep the old parity drive intact while doing this, just in case any issues are encountered while building the new parity drive.
- when the parity build completes you can stop the array and assign the old parity drive to a new drive slot.
- start the array and Unraid will start Clearing the old parity drive. The array is usable while this is going on
- when the Clear completes the drive will shows as unmountable and you will have the option to format the drive to create an empty files system and make it ready for receiving files.

You need to disable docker and then re-enable it to get default Docker related folders created.

I am reasonably certain that if a scheduled time is missed, then nothing happens until the next scheduled time based on the fact that they are initiated by 'cron' and that is the way that 'cron' works.