itimpi

OK. That shows that somehow you have ended up with the same file on both array and cache which should not happen in normal operation. In such a case mover does not do anything as it does not know which is the 'good' copy. The most likely cause would be that at some point you started the array without the cache disk present and so the system created fresh copies of these files on the array. You need to decide which copy (if any) of each file you wand to keep and remove the other one.

it is worth pointing out that you can set individual alert levels for each drive by clicking on them on the Main tab and setting custom levels from there phat over-ride the global setting for that drive

This will leave them on the cache drive as No tells mover to ignore them. If you want them on the array then change them to Yes and run mover (or simply delete them off the cache if you are certain they are empty). After that you can set them to No so they remain on the array if new files are created in those shares.

If it will not move with use Cache=-Yes and dockers and VMs both disabled (to make sure they are not holding files open) then I would suggest enabling mover logging to see what it reports.

Cache preferred means move files TO the cache. You need Use Cache=Yes to get them to move FROM the cache. You should read the help for the Use cache setting that is built into the GUI to see the effect of the different options and how they affect mover.

It is not normal to create any specific user for a docker as this is handled internally within the docker container and is set up by the container author. Users are therefore NOT normally set up at the Unraid level to support docker containers.

When writing new data Unraid works at the file level and selects an appropriate drive when a file is first created. Once a file has been selected then Unraid will keep writing to that drive until the file write completes. If the disk runs out of space while writing the file then an an error occurs and the write fails. There is a Minimum Free Space option for the cache drive under Settings->Global Share Settings and when the free space on the cache falls below this value Unraid starts by-passing the cache and writing new files directly to the array bypassing the cache. Ideally this option to be set to be larger than the largest file you are likely to be writing to Unraid. For existing files to be updated Unraid simply selects the drive already containing the file. there is an option to run mover immediately on the Main tab. There is an option to schedule mover runs under Settings->Scheduler. There is also the Mover Tuning plugin allowing for more sophisticated automated control. Moving cache/dockers/VMs is easy enough although it can be time consuming. It is basically just a copy operation.

As far as Unraid is concerned eSATA should look just like another SATA device as eSATA is just slightly different cabling compared to SATA. A lot depends on how well the eSATA support at the disk end of the link is implemented.

No. There is no way to achieve what you want in the current Unraid as mover does not take age into account when moving files. The only way I can think of to achieve what you want is to customise the ‘mover’ script to suit your particular use case. If you changed it to only move files over a certain age then you could run mover more frequently (e.g. daily) which might reduce space pressure on the cache drive.

I agree that having the ability to move data in preparation for removing a drive would be a nice feature. However I am not sure it is that critical as moving the data off the drive is not needed if you are intending to replace it and rebuild its contents (in fact this may be something you do NOT want to do as it may hasten the demise of a drive that is failing). Have you tried using the Unbalance plugin to achieve this? Note however that the point about it speeding up the replacement is wrong. When you replace a drive then every sector on the replacement drive is written regardless of whether it contains data or not.

The lines you highlight do not appear in my Unraid boot! Are you starting something (perhaps via the ‘go’ file) to output them? If so that might also be what is doing the download. Are you perhaps running a Trial license (as that would do an online check of the license)?

You should post the system diagnostics zip file (obtained via Tools >> Diagnostics) to allow for informed feedback rather than random guesses. A USB drive failure would not cause any data loss as the only user information stored on it is configuration information. If there IS some data missing then it has some cause other than the USB drive failing. Your description raised some questions in my mind: What lead up to the problem you are encountering (e.g. power loss)? Did you redo using the same USB drive or did you use a new one and transfer your license to the new drive? Did you restore your drive configuration from a backup of the USB drive, from a screenshot or from memory? If the latter how sure are that you have selected the correct parity drive(s)?

You can have multiple disks in the cache to give redundancy. You can use the CA Backup plugin to backup files from the cache to the array.

If I have read the diagnostics correctly the the ata1 and ata6 devices correspond to the parity1 and parity2 drives - not disks 1 and 6. you are correct to say that this type of error is a connection issue typically relating to the SATA connection to the drive in question. Resets of this type have the symptom of slowing down disk I/O due to the delays introduced as the drive(s) continually reset. To identify the drives you need to start by searching the syslog for the ataX type strings until you find the entries where they are associated with a particular disks serial number to identify the correct drive(s).

If you want to try and sort out some of the files in the lost+found folder then the ‘files’ Linux command can be useful in helping work out what the content type is of the files.

If you have another license then in is possible to run a second instance of Unraid in a VM and pass the additional drives to it. That is how I actually run an Unraid test environment on my main Unraid server. Whether that would be better than having a second server depends on whether you want to save money and are not too demanding on what you want from the second Unraid instance.

The default location for vdisks is specified under Settings -> VM Manager, but you can specify any location for a vdisk when setting up a VM.

There is nothing that stops you using array drives for everything! The reason that this is often not the recommended way to get the best out of your Unraid server is that writes to array drives are much slower than writes to non-array drives. This is even more so if the non-array drive is an SSD. If you are running ‘VMs or docker containers this can mean their performance is much worse if they are running of array drives compared to non-array drives.

The data on all the ‘good’ disks will be safe and will not need any sort of recovery. At the very least you will be able to create an array of those disks and keep their data intact. The question is what to do about the disks which are in a suspect state to try and recover all their data. There is a good chance the data on the other disks that ‘failed’ may also be recoverable so keep those disks intact. Do you still have the 2TB disk that you replaced with another disk? If so it’s data is probably intact if it has not physically failed and thus recoverable. Have you taken any other action that needs to be taken into account?

No. The only impact of a parity sync should be degraded file access performance. if you want more informed feedback you should provide system diagnostics zip file (obtained via Tools>>Diagnostics) taken while the problem is occurring to see if anyone can spot something.

The fact the disk is still showing should mean it is being emulated. Click on the disk and select the option to run a file system check.

Best way forward will be to: stop the array remove the physical drive start the array and the drive should be emulated if it still shows as unmountable click on the drive on the Main tab and select the option to check the file system report back on the results of the check as the output will help with suggesting the best way forward. Keep the physical drive safe in case you later want/need to try and recover some data off it.

Nothing springs out as indicating any sign of problems with either drive as far as I can see.

Unassigned drives are not part of the array and do not participate in User Shares. It is up to the user to manually manage their contents as they are not part of Unraid’s automated management.

Sounds quite reasonable. The speed you quote is in Bytes/sec whereas network speeds are quoted in bits/sec. to allow for overheads a simple translation will be of the order of 10 to 1. On that basis you are achieving 70-80% of the maximum theoretical speed of the network, let alone any limitation imposed by I/O limits at client or server.