itimpi

The process is covered here in the online documentations accessible via the ‘Manual’ link at the bottom of the GUI.

Yes - parity is only important after a drive fails to reconstruct its contents.
 

Yes.  
 
The key thing is to not have any data drive accidentally assigned as a parity drive as that will end up losing its contents.
 
if any share have includes/excludes for specific drives these will need to be checked (and if needed corrected). 
 

Not that I know off.
 
The way to handle this will be:
make sure you have notifications enabled so you can get an email if a drive fails set up secure remote access using either My Servers plugin or using WireGuard VPN built into Unraid.   That gives you the ability to monitor and control the server remotely.

There is also the ‘mc’ (Midnight Commander) command from a terminal window which is friendlier than using the command line

Level 2 would be correct for your example as you only want to allow the Ozark level to exist on multiple drives.    Note that there is a bug if you are running 6.10.0 rc2 where changes to share settings do not seem to take effect until you restart the array.
 
The change only applies to new files.   It would take Manual action to sort out any files that are already on the wrong disk.

Using the Parity Swap procedure the system does not start over-writing the contents of the old parity drive until it has successfully copied its contents to the new parity drive.  If for any reason you get a failure during this stage you still have the contents of the old parity drive intact for recovery purposes.  As long as the parity copy completes the new parity drive takes over the task of emulating the failed data drive while that rebuilds.

You have corruption on disk 4 so you need to run a file system check on that drive.  File system corruption often causes the tort of symptoms you are seeing.
 

The Parity Swap procedure is not appropriate for replacing a failed parity drive  You should just be able assign the replacement drive and start the array to rebuild parity.
 
The fact it appears to not be showing up to assign suggests an issue at the hardware level. You might want to carefully check power and SATA cabling to the drive.  Posting  your systems diagnostics zip file might also help with diagnosis. 
 
 

You can find the Parity Swap procedure which handles this scenario in the online documentations accessible via the ‘Manual’ link at the bottom of the GUI.

You cannot change the file system type without reformatting (which effectively wipes the current data).   The only way to achieve this is to first copy the data elsewhere before reformatting the drive and then (if wanted) copy it back.
 
Parity is maintained when you reformat so will not need rebuilding.
 

You do NOT have the files mirrored - they are simply different views of the same files.
 
Usef Shares provide an aggravated view of files within a top level folder on all array and pool drives. You might want to read the online documentations accessible via the ‘Manual’ link at the bottom of the GUI to find out more.

You can use the procedure documented here in the online documentation accessible via the ‘Manual’ link at the bottom of the HUI.

As far as I know there is no way to change the format keeping the data intact.
 
As to what format is most suitable that does not have a 4GB limit it will depend on what systems you want to move the drive between.    For example if it Windows and Unraid then NTFS is probably the most convenient to use.

No.  With 6.9.0 you can have multiple pools (with user specified names), and any of them can be set to cache a share.
 
Under settings -> Identification.
 
 

The easiest thing would be to edit the config/network.cfg file on the Unraid flash drive to change the static IP to one in the new range
 

du is known to often not give correct results on multi-drive btrfs format arrays.

It looks like you have been getting messages about drives resetting ever since the system was booted on 7th Jan.   I did not spot anything obviously wrong in the SMART reports for the drives, so these issues may well be related to the power/SATA connections to the drives.
 
I would suggest that you shutdown the server, carefully check all the power and SATA cabling is well seated, and then power up the server to and get new diagnostics.
 
 

If the extended SMART test is failing then the drive should be replaced ASAP.   Even if you have/had cable issues this would not have affected the extended SMART test as that is internal to the drive,
 

Unraid does not split files across drives, so you need to make sure a disk has enough space to contain the vdisk when it grows to its maximum size.   If there is not enough space then the VM will stop working when the drive runs out of free space.
 
another possibility is to bypass this problem by passing a complete physical drive to a VM.
 

Do you have the My Servers plugin installed?  If so you can get your key file via that. 
It would also be included in any local backup you have made of the flash drive.
There is also the possibility you have it attached to an email from Limetech.
 
In the worst case you can email Limetech and they should then be able to help but that may take a bit longer to get resolved.

All drives that are visible to Unraid when starting the array count towards the licence limit.
 
If you are passing a disk controller through to your VM then drives attached to it will not be visible to Unraid and thus not count.  However if you are passing through individual drives (i.e. ones that show up under Unassigned Devices) then they DO count.

Have you restarted the array since making this change?   I believe there is a bug in 6.10.0. Rc2 where such a change will not take effect until the array is next started.
 
note that as long as you have set the Minimum Free Space setting for the cache pool (set by clicking on the pool name on the Main tab) to be larger than the biggest file you intend to copy then even with the Yes setting Unraid will start by-passing the cache when the free space falls below that value.

Unraid will not do that -  you must have configured something to make that happen.   The most likely culprit I can think of is the CA Backup/Restore plug-in being incorrectly configured to point to that location for storing backups.
 
the only way I can think of to recover the data will be to restore it from your backups.T

Seems unlikely that Unraid will be directly vulnerable as it does not use Apache.
 
I guess it is possible that VMs or Docker containers that use Apache could be vulnerable.   Quite what knock on effect this might have if one got compromised is unclear as they run within controlled environments isolated from core Unraid.