JorgeB

Yep, PSU could also be the problem.

I meant in the server, use different cables or physical slot.

Disk1 is rebuilding but everything looks fine so far, you can also swap cables/slot with another disk just to rule that out if it happens again.

That is also OK but I meant creating a bug report here: https://forums.unraid.net/bug-reports/stable-releases/

See here then post that log after a crash.

IIRC disk has a different MBR signature and due to a bug Unraid doesn't consider it a valid partition, LT was suppose to fix this but guess it fell though the cracks, you should create a bug report.

Run a correcting check. You'd need to have pre-existing checksums for all files (or be using btrfs).

That's normal for Seagate drives, it logs the total number os seeks, same of the RAW_READ_ERROR, more info here: https://forums.unraid.net/topic/86337-are-my-smart-reports-bad/?do=findComment&comment=800888

You have multiple disk errors on the log, but the advice remains for disk1:

This is usually a sign of a device dropping offline, confirmed by the syslog: Apr 7 16:30:47 Tower kernel: sdh: detected capacity change from 600127266816 to 0 Check/replace connections and post new diags after array start.

There shouldn't be, unless you were writing to the server when it lost power, in that case those files would likely be corrupt, if that was not the case sync errors are usually the result of parity not being 100% in sync.

Stop array, unassign that disk, start array, stop array. re-assign the disk, start array to begin rebuild.

Should not affect, but IMHO it would be better to backup and re-format the disk to get rid of those errors.

Post new diags after the errors previous one didn't have those.

Please post output of: hexdump -C -n 512 /dev/sdX replace X with correct letter.

Stock Unraid can't spin down SAS drives, install the plugin, you should also update to latest stable.

Errors during scrub don't point to any files, which is strange, but from my googling it appears that when that happens the blocks are from orphaned data, so you should be able to copy everything from that disk.

Yes, I didn't look close enough, also didn't look at what was being transferred, @theruckI don't know what kind of performance you expect with very small files but in my experience, when using disk shares, Unraid is no slower than any other SMB share, user shares on the other hand can be a lot slower, especially with small files, but you'll always get much lower performance when transferring small files vs large files. Here's an example with even smaller files: Unraid Windows share on another PC FreeNAS share

v6.9.2 is out, worth testing to see if the patch included in the new kernel helps.

Post new diags, before rebooting.

Try this.

Yes, newer kernel can detect previously undetected corruption.

Looks more like a power/connection problem, replace both cables and try again.

Sorry, no idea what that is.