JorgeB

You must leave your last valid key file installed, and correctly named, and only that one.

Mar 11 03:33:13 Tower kernel: ahci 0000:00:17.0: Found 1 remapped NVMe devices. Mar 11 03:33:13 Tower kernel: ahci 0000:00:17.0: Switch your BIOS from RAID to AHCI mode to use them.  

Constant disk errors with that disk, not even a SMART report is available, replace/swap cables and post new diags.

It's logged as a disk problem, and theses attributes being non 0 for WD drives is bad news:
 
ID# ATTRIBUTE_NAME          FLAGS    VALUE WORST THRESH FAIL RAW_VALUE   1 Raw_Read_Error_Rate     POSR-K   200   200   051    -    2106 200 Multi_Zone_Error_Rate   ---R--   200   200   000    -    12  
You can give it a second chance, but most likely there will be more errors soon, especially if those attributes keep climbing.

You are using USB, retry with SATA.

Mar 11 09:22:21 NAS kernel: sd 9:0:0:0: Power-on or device reset occurred Mar 11 09:22:21 NAS kernel: sd 9:0:6:0: Power-on or device reset occurred Mar 11 09:22:21 NAS kernel: sd 9:0:1:0: Power-on or device reset occurred Mar 11 09:22:21 NAS kernel: sd 9:0:2:0: Power-on or device reset occurred Mar 11 09:22:21 NAS kernel: sd 9:0:5:0: Power-on or device reset occurred Mar 11 09:22:21 NAS kernel: sd 9:0:3:0: Power-on or device reset occurred Mar 11 09:22:21 NAS kernel: sd 9:0:4:0: Power-on or device reset occurred  
Still looks like a power/connection issue.
 
Unassign both parity drives, start array, stop array, reassign both parity drive, start array, ideally after trying to fix the issue, or it will likely happen again.

Looks like the docker image may be full:

 
failed to start daemon: write /var/lib/docker/volumes/metadata.db: no space left on device Try recreating:
 
https://docs.unraid.net/unraid-os/manual/docker-management/#re-create-the-docker-image-file
Also see below if you have any custom docker networks:
https://docs.unraid.net/unraid-os/manual/docker-management/#docker-custom-networks

Just choose one of them, mostly to mark the thread solved.

There are ATA errors for parity, not necessarily what caused the issue, but still should be fixed, replace cables and see if more errors are found on the next check.

Try this:
 

If you have a backup you can try the repair, but btrfs repair is far from optimal, it can't repair a lot of issues, and in some cases it can makes things worse, if that happens recommend recreating the pool and restoring the data from the backup.

You need to reset them, see here:
https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=700582
 
 
Suggest converting those to COW, btrfs cannot correct NOCOW data, since it's not checksummed.

See here:
https://docs.unraid.net/unraid-os/manual/changing-the-flash-device/#what-to-do-if-you-have-no-backup-and-do-not-know-your-disk-assignments

If you are getting errors with the two very different kernels, and assuming the Ryzen specific issues have been taken care of as linked above, it suggests a hardware issue.

Type N to keep the btrfs signature, then type
write followed by enter.
 
Repeat the same for the other NVMe device (/dev/nvme1n1), a btrfs signature should also be found, if yes when done post the output of
btrfs fi show  

For the nginx errors try booting in safe mode and/or closing any browser windows open to the GUI, only open when you need to use it then close again.
 
Also this can make the server hang:
Error: Macvlan and Bridging found Change the docker network to ipvlan.
 
Finally, disk1 appears to be failing, run an extended SMART test to confirm.

You should get close to that with turbo write.

In that case the Unraid version is important, it wouldn't be the other way around, update the old server to the newest release, it should then mount the new disk.

Disk is actually smaller:
 
User Capacity:    3,881,877,569,536 bytes [3.88 TB]  
Which is strange, for a long time now that all disks from the same announced capacity have the exact same size in sectors, even from differing brands, I'm afraid you will need to get a different disk.

Try this:
https://forums.unraid.net/topic/154030-6128-log-spammed-with-references-to-unraid-apiphp/
 

Mar  8 22:22:45 blinky emhttpd: device /dev/sdo problem getting id Mar  8 22:22:45 blinky emhttpd: device /dev/sdl problem getting id  
This means some devices are being detected in duplicate, connect only one cable from the HBA to the external enclosure.
 
Also disk4 got disabled, rebooting won't fix it, you will need to rebuild, if the emulated disk mounts and contents look correct.

Pool is correct, but with btrfs the parity size is included in the capacity, used and free space will be correct though, also note that raid5/6 with btrfs is not ready for production, I would recommend using zfs raidz instead.

If nothing was written to the emulated disk you could do a new config, but then will need a correcting parity check, and that will take the same time, that's why we usually recommend rebuilding instead.
 
Not with out the diags showing the error, but I would say sleep can be a good suspect, try running the server without sleeping for a few days.

Are all the parity check errors expected?
 
Both the docker and libvirt images are new, the former can easily be recreated if the appdata still exists, do you have a backup of the latter, also apppdata in case it's needed?

They should not, note that writes will still be slow because they will be limited by the parity HDD, and lack of trim may also degrade write performance after some time, other than that it should be fine, and if it's not there will be some sync errors during the parity checks, so you will know there's a problem.