itimpi

The easiest way is to make the pool redundant by adding another drive to it and running it in RAID1 configuration. However that is still not foolproof as things other than drive failure can cause data loss so you should still have a backup strategy for the data such as using something like the appdata backup plugin to make regular backups to the main array.

If all the data drives are as you want them (including nothing in the disk1 slot) then you could use Tools-<New config with the Preserve all option and then correct the parity disk assignment before starting the array to commit the change and start building new parity based on the new data disk set. One question - what made you think that disk1 had failed? A drive can be disabled for all sorts of reasons other than the drive actually failing with by far the most common being issues with the SATA or power cabling to the drive.

SSL normally only applies to encrypting network traffic - not encrypting disks.

It was not clear from your screenshot, but do the extra folders/files start with a dot? If so this is normally a MacOS thing and there should be a setting somewhere to stop macOS creating these on network shares.

It is the Plex transcode folder that is using nearly all the space.

That could explain your issue. The parity swap procedure is meant to run to completion without the system being shutdown or rebooted. Maybe this needs to be clarified in the instructions?

That is basically the procedure that is documented for handling unmountable disks 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. Stopping and then restarting the array in normal mode is all that was required in the last step (assuming you meant went through a reboot sequence).

Unraid does not check for the preclear signature on a parity drive as it is going to overwrite every sector with parity information anyway (even if the last part is just zeroes). That would only be true if the remainder of the parity drive was going to be written when a new data drive is added. As was mentioned earlier it is the data drive that is cleared so that no new parity information needs to be written. Even when adding a drive the preclear is optional as if necessary Unraid will clear it anyway as part of the add process so that no new parity information is required to be written. If you are replacing a parity drive (or a failed drive) then whatever is already on the drive is going to be completely overwritten so need for preclear unless you want to do it as a stress test.

You have to either set the mirror to flash option (easiest) or put the Unraid servers /iP address in the remote server field. I suspect you have not set either of these?

The system restarting by itself suggests a hardware error. Unfortunately diagnostics will not show what happened before the reboot. To get persistent logs that survive a reboot you need the syslog server, and with that the Mirror to flash option is the easiest to use to get the syslog in the ‘logs’ folder on the flash drive.

That is no longer required in the 6.12.x releases as setting a share to Exclusive mode achieves the same performance benefits without needing the rename.

There is no fully automated process for this, but what you need to do is covered 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.

If the share is set to be exclusive these are effectively the same thing anyway.

The flash drive is still at /boot if accessed internally from within Unraid. If you want to access it as a share instead it is as the 'flash' share (but by default the share option is disabled in recent Unraid releases). These have both been the same for many years.

not sure what you are really asking for here? If you are 6.12.x or later releases with exclusive mode enabled for the appdata share then accessing /mnt/user/appdata is as efficient as accessing the drive directly

I would get the memtest86.com version anyway. It is a much more recent version so probably does any test better. It unfortunately is not included as standard with Unraid for Licencing reasons.

Do you have the swap file plugin installed? Just asking as by default Unraid does not use a swapfile. This is normal if you boot in UEFI mode. You need to either boot in legacy mode to get the Unraid supplied version to run, or download a version from memtest86.com that can boot in UEFI mode.

I wonder if @PassTheSalt does not have a parity drive? In such a case the benefit from the cache is far smaller as individual drives can then be written as fast as the drive can handle.

I don't even remember such an option from him Note that my script can optionally do binary compares as well (albeit much slower than simple name compares).

This would have wiped the file system then. If you have not written new data to the drive it is possible disk recovery software something like UFS Explorer on Windows could recover data. However they tend not to be free to use although you can normally run a free test to see what it might recover.

The only time it is definite that you should RMA is if a drive starts failing the Extended SMART test as cable issues are by far the most common cause of situations like this However if a fault follows a drive even after things like cable swaps then maybe it is also time to RMA the drive.

That is not unreasonable as they were new drives. What might have been overlooked at the time was if the emulated drive was also on the list of those to be formatted when the format option was allowed to proceed. A nice GUI enhancement would be to have format button against the individual drives in the Main tab so it was clearer what was going to be formatted. Not sure, though, how easy that would be to implement.

Not that I know of. I would suspect that there are problems running it on recent Unraid releases. The UD version is probably now the best preclear version to use and at least it is actively maintained. If you really need the Joe L version I may have a copy somewhere in my archives that I could PM to you.

In this case I suspect that when it came around to formatting the newly added drives it was not noticed that the emulated drive was also on the list of drives that would be formatted. As you mention best chance of recovery at this point is from the original drive.

Yes it has not been updated in a very long time as there seemed little point unless I was going to put the effort into trying to convert it into a plugin with a GUI front-end. A point to note is that it only looks at main array drives - does not include pools (which I guess could be done as an enhancement if there was demand for it). Having said that I have not validated that it still runs fine on the 6.12 releases but it should as far as I know.