itimpi

Why bother to back up docker.img.? If needed it is trivial to retreat the docker.img file and reinstall all your containers with settings intact as described 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.

You should just check that the boot completes. It should come up as if was a ‘new’ Unraid install with nothing setup or configured. You can then just shutdown Unraid as you normally would. At that point copy across the config folder and reboot to get all your settings/customizations back in place.

It is fine to format them AFTER adding them to the array (and is in fact required). What you must not do (as many users seem to do) is format them in UD after the Preclear but BEFORE adding them to the array.

Copying the config folder restores all your settings (including plugins) so there is nothing to download and everything should work unaffected. You can always start without copying the config folder just to see if the flash drive will even boot. This can be quite useful in the event a config file has been corrupted and is causing problems (although that should not stop it booting.).

You can always use the USB Creator tool and then copy the config folder across, although in my experience the manual method is more reliable. If you do it with a different USB then you will need to go through the licence transfer process

You can use the procedure documented here in the 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.

It is a single partition and it is formatted as FAT32 with a label of UNRAID

You can always recreate the flash drive and then copy back the config folder from your backup (which contains all your settings).

You can but any access to the main array will have degraded performance.

Try running the make_bootable.bat file from the flash drive (in Administrator mode). However that is only relevant if booting in legacy mode.

I have never heard of simply copying the bz* type files stopping the flash drive from booting. I assume you did not format the flash drive (as that would require running make_bootable afterwards)? Not being able to get into the BIOS suggests something else is going on at the hardware level rather than the Unraid level. Probably need to resolve that first

It is not SMART that wakes it up - the syslog shows Unraid attempting to read SMART information AFTER a dtive that was previously spun down has spun back up again (typically because a read or write access was made.

You are likely to get better informed feedback if you attach your system’s diagnostics zip file to your next post in this thread so we can see what is going on.

you realize you are responding to another user - not a Limetech employee?

Note that parity is not a substitute for backups as it only protects against dtive failure - not other ways of losing data. For anything important you cannot afford to lose you need a backup that is not on the server (and ideally off-site).

Do you have any parity drives? If so then remember no parity drive can be smaller than the largest data drive.

There are instructions for manually upgrading/downgrading to any Unraid release for which you have the zip file for the release 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 6.11.5 zip version is available from https://unraid.net/download

It sounds as if you really want the MyMedia share to end up on the main array? Perhaps you had that share set with the cache pool as Primary Storage, the array as secondary storage and the mover direction to be pool->array? If so setting it back to those settings will move things back to the array. Another possibility is that you had only the array set as Primary storage and no secondary storage for the mymedia share and were exploiting the fact that mover will do nothing with such shares so any files created on the pool stay there? If so you need to get all the files back onto the main array; manually create that folder on the pool; and then manually move the files that should be on the pool back to the pool.

Not sure when in the sequence of steps you outlined you took those diagnostics.. In the diagnostics there is writing going on to two drives (disk12 and disk17) which will kill performance of the clear (which is presumably to one of those drives). Stop the writing to the other drive and things should speed up dramatically.

Not quite sure I understand. You can always use a pool (whatever type and number of drives) as an Exclusive Share as long as all files for the share are on the pool.

You also need to make sure that the flash drive is set to boot in UEFI mode if required (i.e. no trailing character on the EFI folder) as you can get those symptoms if the flash drive is set for legacy mode and the server needs UEFI mode.

The number of parity drives is the number of drives that can fail before any data is lost. If more drives than that fail then the data on the failed drives is lost, but that on any other drives remains intact.

Add up the size of all the drives not being used as parity drives to get the storage space that is available.

In the current release a pool cannot be secondary storage. That is meant to be coming in a future release. but what the ETA is I have no idea.

That is not the diagnostics - just the syslog. However it is enough to show that you are getting errors on multiple drives. Since you say you have checked the cabling (I assume this is the SATA cabling?) are you sure you do not have a power related issue? Failing that what else is common to multiple drives?