itimpi

Enable the syslog server. 

No problem doing what you mention, and in fact checking out Unraid satisfies your needs before you commit to buying it is always recommended.

Alternatively try the Manual install method.    Unraid does not use GRUB so the message you showed definitely means the flash drive was not correctly created.

Sounds as if the docker.img file may have been reset as the diagnostics show it to basically be empty? 
 
Simply restoring the appdata will not do anything if the system thinks no dockers are installed - it simply puts the working data back for containers but you still need the containers to be installed.
 
You can reinstall containers with their previous settings intact by using Apps->Previous Apps.

According to your diagnostics you have writing going on to disk1, disk2 and in particular disk3.    This will dramatically slow down any parity check while these writes are happening.

Have you checked that the Shares are not set to Export=No (the default) as shares with that setting are not visible on the network.

The simplest solution is to replace the failed disk and rebuild its contents.    You solution is valid if you do not intend to replace the failed drive.

You did not go to the current documentation that is here in the online documentation accessible via the ‘Manual’ link at the bottom of the GUI or the DOCS link at the top of each forum page. The Unraid OS->Manual section in particular covers most features of the current Unraid release.

The speeds you quote are more than one would normally expect for writing to a parity protected array so doubt there is anything wrong.    You will never get close to the disk raw speed because of the way Unraid writes data as described here 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 - nowadays the Clear runs with the array online.   In terms of time it is probably around ~2 hours per TB (about the same as the write phase of a pre-clear).

If they are both HBA then it is just a case of re plugging the drives.

Probably better to refer to this section of the online documentation accessible via the ‘Manual’ link at the bottom of the GUI or the DOCS link at the top of each forum page. The Unraid OS->Manual section in particular covers most features of the current Unraid release.    It is better to use the documentation for the current release rather than legacy documentation that may no longer be valid.

Replacing a disabled disk is not sufficient to remove the disabled state.   To do this you need to rebuild them as if 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.
 
Note that a drive being disabled does not necessarily mean there is a problem with the drive.   More often than not it is a problem with the power or SATA cabling to the drive.

That looks like the standard screen if the array is not started.   Have you enabled Autostart under Settings->Disk Settings?   If you have you should post your system's diagnostics zip file so we can see what is happening.

You need to run with -L (and without -n).

You would need the template entry for that app which is stored on the flash drive under config/plugins/dockerman/templates-user to be on the flash drive on the other system for it to show up under Apps->Previous Apps.

If you used move from the command line then you probably encountered the behaviour described in the Caution in this section of the online manual.   

Unraid does not need a GPU, but your motherboard might.   Have you checked the motherboard manual?    It could also be a BIOS setting.

This topic is covered here in the online documentation accessible via the ‘Manual’ link at the bottom of the GUI or the DOCS link at the top of each forum page. The Unraid OS->Manual section in particular covers most features of the current Unraid release.

My guess is you have the Dynamix File Manager plugin installed on one server and not the other?
 

Yes - the shares unexpectedly showing as protected have all their files on disk1 and appdata also has some files there.
 
Note that simply changing the primary storage to a pool and removing the secondary storage does NOT automatically transfer files onto the pool.  To get the files into the right location you will need to:
stop docker and vm services under settings as these will stop any files they have open from being moved. for the shares you want to only be on a pool set the pool as primary storage and the array as secondary storage. set the mover direction to be array->pool manually run mover from the Main tab to get files moved onto the pool. when mover finishes you can remove the secondary storage=array as it is no longer needed re-enable docker and/or vm services (optional) enable the option to use Exclusive mode shares under Settings->Global share settings.   This gives better performance for shares with all files on a pool by by-passing Unraid’s fuse layer for such shares.

You need to rerun that check without -n and add -L

You should be able to copy the syslog files without shutting down the syslog server.

That shows something is actively configured to issue the shutdown command, so it is not a crash.
 
Have you checked that you have nothing configured to run at that time?  Feels like it could be a User Script.   One small clue is that is using the ‘powerdown’ command to do this rather than the ‘shutdown’ command.   Have you tried looking at something like /etc/cron.d/root to see if it contains an entry for that specific time?

There is no way to tell what the parity check is doing in terms of any files that might be affected (parity does not understand the concept of files).  It just knows how far through the check it has got and it tells you that in the GUI.
 
Chances are that since disk2 is a new large drive all new files are going to it thus explaining the write behaviour.
 
Probably the best thing to do at this point is to run a check filesystem on all array drives to check there is no corruption at that level, and assuming it all looks good run a parity check with the option to correct errors set.