itimpi

Other than the fact the drive will be spinning there should be little risk. Not sure that you even have to be in Maintenance mode to run the SMART test - try clicking on the drive and see if it is needed (not in a position to check myself at the moment).

Unraid will disable a drive any time a write to it fails. More often than not this is due to an external factor (e.g. cabling, power, etc) and is not a fault with the actual drive itself. When the drive is disabled then Unraid stops writing to it switching to trying to 'emulate' it using the combination of the other drives plus parity. When you did a New Config you effectively told Unraid to revert to using what it finds on the physical drive. If the drive is not actually faulty this will be the contents at the point the drive was disabled and will not have any files that were written to the 'emulated' drive after the physical drive was disabled. In many cases this means the vast majority (if not all) files are available again. You just need to be aware that any recent updates have been lost.

Have you looked at the WireGuard VPN support that is now built into Unraid 6.8?

Yes. Once you have emptied a disk you can click on it on the Main tab and change the file system type to e an unencrypted one. When you return to the Main tab it should show as unmountable with an option to format it. After formatting it then it will be available to hold files on the now unencrypted drive. Having said all that I see no obvious reason to not keep the drives in encrypted form as they should be readable on any new Unraid build, and also on a standard Linux system.

You do not even need to start the array if all you want to do is run a pre-clear !

There is no way to do in-place decryption. The only way to get a decrypted copy would be to copy the data to another location that is not encrypted.

Yes, but in that case it will be the parity drive that gets lots of writes and all the data drives that get lots of reads.

That is exactly what I would expect to see after a rebuild The rebuild process had to write to every sector on the drive being rebuilt so it is not surprising there are a lot of writes on that drive.

I do not understand what you think is wrong? If you are rebuilding a drive then Unraid will be reading each sector from all the other drives to calculate what should be in that sector on the rebuilding drive and then writing the rebuilt sector to the drive being rebuilt.

What is wrong with the WireGuard VPN option built into Unraid 6.8?

No problem. stop arraY; Unassign drive; start array

It depends on when they are needed. If only after the array starts then User Scripts could be used.

This is not a feature that Unraid provides. With modern drives this sort of issue should be handled Internally by the firmware on the drive and any bad sectors reallocated to use good ones.

The normal recommendations are a USB2 drive and if possible use a USB2 port as they seem to be more reliable, and Unraid gains no perceptible performance gain from USB3 as it runs from RAM. 16GB is plenty of space.

Easiest thing would be do copy them to /usr/local/bin as part of the boot process and then set the execute permission. You can do this either via the config/go file on the flash or via the User Scripts plugin.

The syslog showed that you formatted the drive Unraid thought was assigned to the array. It should not have been showing up under Unassigned devices. Probably worth remembering that you need to be very careful about issuing any format command while in the middle of any data recovery operation.

The problem would have been that you were not actually formatting the new disk but Unraid's emulation of the old disk. The format would have wiped the contents from the emulated disk and updated parity to reflect that. The subsequent rebuild would just have been restoring the empty file system. There should have been a warning that a format is never part of any data recovery operation?

That looks like an empty disk? Did you at any point in trying to recover the disk do a format (as that would have erased the contents)? The syslog suggests that you did Do you have a backup of the data?

The opposite - Raid1 is nowhere near as safe as Unraid parity! With a typical RAID if you lose more disks than you have redundancy you lose everything. On Unraid in such a scenario you only lose the data on the failed disks - all other drives are still accessible as each drive is a discrete file system. This was one of the reasons that made me switch to Unraid in the first place. However as several previous posts have mentioned any data that is important should be backed up off the server, and preferably have an off-site copy as well. It is always possible (albeit unlikely) to have some sort of catastrophic failure that was not catered for.

What browser are you using (and what version). NoVNC has always seemed a bit susceptible to not working correctly with all browsers. I have personally have often had problems with noVNC in the past so I always have a free-standing VNC client as a fall-back.

Have never done a large-scale replacement of drives like you are doing so have never really had to decide. I would probably not bother doing it every time, but I think I would do it at least once to give me confidence that the replacement process was working as expected and I got 0 errors. I would also do one before repurposing any removed drives. What is the state of backups if at any point you DO get any errors reported?

The Dynamix webGui is what is now shipped as the standard Unraid GUI (assuming that is what you are asking about)

No. It means that an empty 6TB drive will not start being used. When the other drives get down to 6TB the next mark of 3TB comes into play and the drives will start being used (in ascending order) until they get down to 3TB free, etc

In Principle the parity check is not required although some people seem to like to carry it out as a confidence check ! If you do run it there should be 0 errors reported.

It is probably because XFS has relatively recently been upgrade to support more features going forward.