trurl

This is exactly and only what parity is for, to rebuild a missing disk. And likely no data would be lost if a disk failed assuming parity plus ALL other disks are OK. So this is a scenario where backup doesn't come into play. You seem to have some misconceptions about parity. Make sure you setup Notifications to alert you immediately when a problem is detected. Don't let one unnoticed problem become multiple problems and data loss.

If you examine lost+found, you will find it has random folder and file names. Often if there is a lot of lost+found, it may be easier to recover that data from backups.

When you delete something, parity agrees it has been deleted. Immediately! Parity is realtime. I encourage you to reevaluate your "backup strategy". You don't have to backup everything, but you absolutely must have another copy of anything important and irreplaceable. You get to decide what qualifies. Plenty of much more common ways to lose data besides a failed disk.

I recommend not installing any plugin unless you know why you need it.

I personally never use Mover Tuning.

Note that repair has created lost+found on the 2 repaired disk. Might also happen when you repair disk1. Repair puts folders and files that it can't figure out in lost+found. Since it is a top level folder on those disks, it is also a user share. Linux 'file' command might be able to tell you what kind of data is in a particular file so you can try to open it in an appropriate application to see if you know what it is.

If anything, disk2 seems to be the best of these 3 problem disks. Go to each of your WD disks and add attributes 1, 200 for monitoring. Setup Notifications to alert you immediately by email or other agent as soon as a problem is detected. Don't let one unnoticed problem become multiple problems and data loss.

Might be a good idea to uninstall Mover Tuning plugin until you get this taken care of.

Docker troubleshooting | Unraid DocsThis page offers troubleshooting guidance specifically for Docker containers on Unraid, managed by the Unraid team. For advanced troubleshooting, in-depth technical details, or topics beyond the Unrai

Your appdata and system shares have files on the array. These files are usually always open. You have these shares configured to put new files on cache, but existing files on the array won't be moved because there is no Mover action because there is no Secondary. Also, nothing can move open files so you have to disable Docker in Settings before these can be moved.

config folder on flash contains all of your configuration, and is all you need to get all of your configuration going again on a new install. config/super.dat is your array assignments, config/pools folder is your pools. config/pro.key is your license. After you boot you will have to do a license transfer to the new flash in Tools - Registration. Changing the boot device | Unraid DocsThe boot device is critical to your Unraid server as it stores the operating system, configuration files, and license. (For typical USB installs this is a USB flash drive; with internal boot it is ano

Your docker templates are on the boot drive, in config/plugins/dockerMan/templates user. These are just the settings you made in the Unraid webUI when you installed or updated a container. These templates can be used to reinstall your dockers with those same settings using the Previous Apps feature on the Apps page. But... Your appdata was probably on cache (it shouldn't be on the array). Appdata is the working storage of each container application. Anything the application needs to know, such as settings made in the application webUI, or a database the application might keep, for example, is in its appdata. Without appdata, the application in your container is a new install.

The path to the boot files is just the same as it was before, /boot, so as far as the plugin knows, there is no difference.

You have the appdata backup plugin installed.

Attach Diagnostics ZIP to your NEXT post in this thread.

Disk3 is probably OK then for now.

https://docs.unraid.net/unraid-connect/automated-flash-backup/#restoring-to-internal-boot

If you transferred your license to TPM, then your flash drive has been blacklisted.

Attach Diagnostics ZIP to your NEXT post in this thread.

Nobody is going to download all those separate attachments. Diagnostics is a single zip file. If you think Diagnostics downloaded a lot of separate files and folders, it is because your PC automatically unzipped them. Find the single zip file wherever downloads are saved, and attach that to your next post. Also Not possible. You can boot from one of your storage devices, but the license must be either on a flash drive with GUID, or on TPM. Unless you did TPM, you probably just need to put your flash drive back in so it can find the license in its original place.

Not sure what you misinterpreted. This is true, since the bad disk isn't involved at all in rebuilding to a new disk. It is replaced. Less true if multiple disks are known to be bad, since all other disks must be reliably read to reliably rebuild a disk. One of your disks had a lot more reallocated than is safe, and I suspect those had been increasing. Not clear if other disks are of concern or not.

Copy is faster and safer than move. Move is Copy from source to destination, then delete from source. Delete is a write operation, so that would be additional writing to suspect disk even though it is just updating the filesystem to mark the deleted blocks available instead of overwriting all the data. Also all writes update parity. You can exclude the bad disk from user shares so there won't be duplicates, then when all files have been copied elsewhere, you can New Config to remove the disk and rebuild parity.

Probably safer to rebuild to new disks.

Do you have a current flash backup?