Syslog is getting flooded with these:
Mar 29 22:35:30 Tower kernel: x86/PAT: ipmi-sensors:6345 map pfn expected mapping type uncached-minus for [mem 0xd943f000-0xd943ffff], got write-back
### [PREVIOUS LINE REPEATED 29 TIMES] ###
Mar 29 22:35:49 Tower kernel: x86/PAT: ipmi-sensors:7517 map pfn expected mapping type uncached-minus for [mem 0xd943f000-0xd943ffff], got write-back
Don't see anything else, try clearing that then reboot and post new diags.
This is a TLC based SSD, and while 25/50MB/s is on the slow side I'd be surprised if you got more than 80MB/s sustained writes to that SSD, if you want more speed look for a 3D TLC based SSD, e.g. 860EVO, MX500, WD Blue 3D, etc.
Diags are after reboot so we can't see what happened, I assume the disk never got disabled.
Disk4 looks fine but there are recent UNC @ LBA errors, so best to run an extended SMART test, if OK run a non correcting parity check and grab diags if it fails again, it could be the HBA since you're using a SAS2LP and those have known issues for a long time.
Fist couple of GBs are cached to RAM, hence the high speed, after that you're limited by the actual device speed, what SSD are you using? Very few SSDs can sustain 500MB/s writes unlike what some think, also make sure it's being regularly trimmed.
Those setting are saved in:
flash\config\plugins\dynamix\dynamix.cfg
Check yourself what they are set to, don't post that file here as it can contain text passwords, look for warning="XX" and critical="XX"
There's a call trace on the syslog but can't say what it is about, I would suggest running the server for a while in safe mode without docker/VMs, if it still crashes like that it's likely a hardware problem, if it doesn't start using plugins and other services a few at a time to see if you can find the culprit.
You need to add another slash to both paths or it will fail, like so:
rsync -narcv /mnt/disks/WDC_WD20EZRZ-00Z5HB0_WD-WCC4M3FD32PK/unraid/divx/Blindness/ /mnt/disk2/unraid/divx/Blindness/
Instead of that make sure mover logging is enable (Settings -> Scheduler -> Mover Settings), run the mover, then please post the diagnostics: Tools -> Diagnostics
You can try but btrfs going corrupt quickly multiple times usually indicates a hardware problem, or were there any unclean shutdowns? If not good idea to at least run memtest.
Very strange, it's obviously not a general problem since nobody else appears to have this issue but can't see what's causing it for you, please create a bug report for this, mention that this is a completely clean OS install (using existing data disks) and include these latest diags.