JorgeB

You can first try using different power cables for that module, or swap with another one, then see where the problem follows.

Do you have notifications enable? There were multiple disks with read errors: May 1 16:53:20 Monstruo kernel: md: disk4 read error, sector=6445062760 May 1 16:53:20 Monstruo kernel: md: disk4 read error, sector=6445062768 May 1 16:53:20 Monstruo kernel: md: disk4 read error, sector=6445062776 ... May 2 01:52:39 Monstruo kernel: md: disk15 read error, sector=588559224 May 2 01:52:39 Monstruo kernel: md: disk15 read error, sector=588559232 May 2 01:52:39 Monstruo kernel: md: disk15 read error, sector=588559240 and then disk9, disk4 and disk15 look more like a connection/power issue, replace cables but also run an extended SMART test on disk15 since it's showing some issues. As for disk9 it dropped offline, so there's no SMART, check/replace cables and post new diags.

Experimenta, tenho uma VM com NIC dedicado e outras duas usando o NIC virtual, e nunca tive problemas com conectividade em qualquer dos casos.

Yes, it will keep everything in sync.

The same it would if the disk wasn't rebuilding, except that it will be slower.

You can use the same flash drive, just backup current one first, you can also use a new one but will need to transfer the key.

Please post the diagnostics: Tools -> Diagnostics

GUI tests won't work on SAS devices, you can still run them manually.

Who are you replying to?

If the external drive is mounted with UD you can even use Windows explorer on a networked computer and all the data will still be copied locally on the server, without using the network, at the same speed it would be with Krusader and without creating the empty folders.

Looks more like a power/connection issue, there was also an ATA error on disk10 at the same time, since it's on a different controller does it share anything in common with the other 4?

There's an option in the UD settings to change the UUID.

Google "interpreting SMART report"

That's normal with Krusader (and rsync), depending on the source you may be able to use Windows explorer, it won't do that.

trurl mentioned that since cache wasn't available new docker/VM images were created on the array, but those are new, they won't have any of your data.

Cache=yes for moving to array: https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=537383 Note that docker/VM service need to be disable, it won't move open files.

If you already recovered any important data, or there isn't important data there, just re-format the pool.

Cache replacement is broken in v6.9.x, you'd need to do it manually or that:

That board doesn't have IPMI, so it won't work.

Those are QLC, after the small SLC cache is used they are terribly slow at writing, live with it or replace them with the much faster EVO.

Pool is in a very bad state, there are some recovery options here you can try, but also make sure to see this for better pool monitoring for the future.

If you upgrade to Unraid v6 you can do it there, if not use another PC.

I missed this part earlier, this suggests a hardware problem, log unlike to catch anything, start by checking fans/temps and/or PSU.

What model SSDs? Low end DRAMless TLC SSDs can cause higher i/o load.