itimpi

As far as I know there will be no way to recover the data without the encryption key. One of the downsides of using encryption.

It 9s really up to you. As you are using a new drive the good thing is that you will still have the old drive available just in case anything goes wrong with the rebuild, so keep it intact until you are happy the rebuild worked as expected. Preclear is NEVER required with Unraid. The only real reason to use it is to act as a stress test of the drive before adding it to the array.

FYI: the diagnostics includes the syslog so it does not need posting separately.

Yes for disk19. As @trurl mentioned you need to work out if you have any residual hardware problems. The process for recovering disabled disks is covered here in the online documentations accessible via the ‘Manual’ link at the bottom of the GUI.

You get entries in the lost+found folder when the repair process cannot find a directory entry to give the correct name. Since the sub-folders have recognisable names you should be able to sort out the original path.

This does NOT clear the cache - it does the exact opposite as that setting indicates you want files moved from array to cache.

Does the contents of the lost+found have recognisable content or only items with cryptic names?

Does its content look like it should? The absence of that folder normally means the repair has been fully successful and all data is intact.

Just to point out that is not part of the ‘Official’ documentation that you can get to via the ‘Manual’ link at the bottom of the GUI. As such it is user maintained.

Look like you have already run the repair. Have you tried restarting in normal mode to see if the emulated drive now mounts? If it does look to see if there is a lost+found folder on the drive as that is where the repair process puts any content it could not correctly identify.

How much RAM do you have. You need at least 4Gb of RAM to run any of the recent releases of Unraid.

One assumes they will improve as manufacturing processes improve! I have found that avoiding the nano/micro form factor and going for ones with good heat dissipation seems to mean USB3 drives last for years as well.

The amount written is trivial in normal use - a few KB per day - configuration changers and a little status information The main OS is run from RAM so after initial load, so it makes minimal use of the boot drive so they seem to last for many years for many people. USB3 drives seem to not as work as well, probably because they tend to run hot which is prejudicial for the lifetime of them.

Have you set the Minimum Free Space setting for the cache pool? It is the free space dropping below this value that triggers Unraid to start bypassing the cache.

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

Are you sure this is true? I regularily mount disks with UD and without the array started although I must admit I have not tried encrypted ones.

All the settings for an Unraid server are stored in the 'config' folder on the flash drive. You could therefore set up a new flash drive with the Plus licence on it and then copy across the 'config' folder from the Basic licence flash (omitting the .key file which is tied to that particular drive) to the new Plus licenced flash drive. If you now boot the existing server off this drive it will come up with all settings intact, and the old Basic licenced flash drive is now free for use in the extra server.

It is possible to boot Unraid off a drive with a different label to UNRAID by editing entries in the syslinux/syslinux.cfg file on the flash drive by using entries of the form append unraidlabel=UNRAID-BACKUP initrd=/bzroot You need to make this change for each of the boot options in that file. You then make sure your backup flash drive has this label. Since it has a different label go your primary flash drive Unraid will not ever get confused about which one you used to boot from. I use this technique to run Unraid in a VM hosted on Unraid (as both host and VM need their own licenced flash drive) but there is no reason it cannot be used for other purposes. If you set up your backup flash drive in this way and then just copy across the contents of the ‘config’ folder (which contains all the settings for a running Unraid installation) instead of the whole flash drive you could achieve what I think you want

No, that is not the option you were told to set for each share. You were told that after setting the Use cache=Prefer setting for the relevant shares, you need Docker to be disabled before running Mover.

Docker is an option under Settings - not a share level setting.

The diagnostics are of limited value as they are just after a reboot. You should set up the syslog server to see if you can capture what is happening when the problem occurs.

You basically need to time how long it takes the slave to power down and then set the master (Unraid) to use a longer time (with a small safety margin to allow for variability in the slave).

Have you checked Settings -> Global Share Settings to make sure that you have not applied a limit there? Since you did not provide your system's diagnostics we cannot check this.

I understand why you are using the share level setting in the way you describe. There are already separate settings for the Minimum Free Space - one on the settings for a share and the other on a cache pool’s settings. The problem is that at the moment if the one for the share is larger than the one set for the cache then the share level value is also used for the cache. I have always thought that was a bug rather than intentional behaviour as it seems to me these two settings should be independent of each other so the cache level setting should always be used for the cache regardless of the value set for the share.

This is all you need to do.