JorgeB

If you mean use an existing pool in a new server you just need to assign all the pool members and start the array, existing pool will be imported.

So that confirms the problem is network related, could be NIC, cable, NIC driver, etc.

It's logged more like a connection/power issue, but since it failed in a different slot it's likely a disk problem.

Jan 12 09:08:43 BadWolf kernel: mlx4_en: eth1: Link Down Jan 12 09:08:43 BadWolf kernel: mlx4_en: eth1: Link Up Jan 12 09:08:52 BadWolf kernel: mlx4_en: eth1: Link Down Jan 12 09:08:53 BadWolf kernel: mlx4_en: eth1: Link Up Jan 12 09:09:26 BadWolf kernel: mlx4_en: eth1: Link Down Jan 12 09:09:26 BadWolf kernel: mlx4_en: eth1: Link Up Jan 12 09:09:26 BadWolf kernel: mlx4_en: eth1: Link Down Jan 12 09:09:26 BadWolf kernel: mlx4_en: eth1: Link Up Jan 12 09:26:04 BadWolf kernel: mlx4_en: eth1: Link Down Jan 12 09:26:05 BadWolf kernel: mlx4_en: eth1: Link Up Jan 12 09:26:05 BadWolf kernel: mlx4_en: eth1: Link Down Jan 12 09:26:05 BadWolf kernel: mlx4_en: eth1: Link Up  
10GbE link is constantly going up/down, try with a different cable, also note that max cable length for direct attach active cables is 10m (about 33feet).

You need to format the assigned devices before use, next to array start/stop button.

I can't why some devices are losing the assignments, is the log from a boot right after just moving the M.2 card?
 
Still as a workaround you can do this:
 
Stop the array, if Docker/VM services are using the cache pool disable them, unassign all cache devices, start array to make Unraid "forget" current cache config, stop array, reassign all cache devices, re-enable Docker/VMs if needed, start array.
 
Alternatively you can also do a new config and reassign all devices, then check parity is already valid before starting the array.
 

Btrfs is detecting data corruption:
 
Jan 16 08:50:46 ZEUS kernel: BTRFS info (device nvme0n1p1): bdev /dev/nvme0n1p1 errs: wr 0, rd 0, flush 0, corrupt 52, gen 0 Jan 16 08:50:46 ZEUS kernel: BTRFS info (device nvme0n1p1): bdev /dev/nvme1n1p1 errs: wr 0, rd 0, flush 0, corrupt 56, gen 0  
This is usually a RAM issue, start by running memtest.

You can just power off, replace devices, when you power back on that pool will be empty, assign new device, start array, format new device.

2.2TiB = 2.42TB
 
Not necessarily:
 
https://github.com/shundhammer/qdirstat/blob/master/README.md
 
 

Those are the monitored SMART attributes.

Make sure you've enabled UEFI support in Unraid, either when using the USB tool or by manually renaming EFI- to EFI in the flash drive.

Those ATA errors usually mean a connection problem, but since it's both disks on a Marvell controller could also be that.

Just re-assign it.

Not sure why you did a new config, that's not used to rebuild drives, starting the array in maintenance mode won't auto-start the rebuild but you could click on "sync" or just start in normal mode, for the encryption key you'd need to use the existing one.
 
Now, and if parity is still valid you can do this (I never used encryption so not sure when it will ask for the key, but when it does use the old one):
 
-You already did a new config so we continue after that
-Check all assignments and assign any missing disk(s) if needed, including the new disk you want to rebuild, replacement disk should be same size or larger than the old one
-IMPORTANT - Check both "parity is already valid" and "maintenance mode" and start the array (note that the GUI will still show that data on parity disk(s) will be overwritten, this is normal as it doesn't account for the checkbox, but it won't be as long as it's checked)
-Stop array
-Unassign the disk you want to rebuild
-Start array (in normal mode now), ideally the emulated disk will now mount and contents look correct, if it doesn't you should run a filesystem check on the emulated disk
-If the emulated disk mounts and contents look correct stop the array
-Re-assign the disk to rebuild and start array to begin.
 
 

Disk1 dropped offline, this is usually a connection problem but since it dropped there's no SMART report, power down, check/replace cables and post new diags after array start.

Constant ATA errors for parity, check/replace cables.

Unraid driver crashed, try updating to v6.10-rc2

It's a known btrfs issue, it happens when there's an odd number of devices in raid1.

Check filesystem on disk2, then you can re-sync parities.

This is the Unraid default for disks, parity partition starts on sector 2048, it means it was partitioned outside Unraid, recently Unraid started supporting that starting sector for SSDs so it doesn't complain, but because of that there are a few less sectors available, to resolve this you'd need to wipe that partition then let Unraid repartition it and re-sync parity.
 
 

Parity can't help with filesystem corruption, the rebuilt disk would look the same.
 
Filesystem corruption can be the result of for example an unclean shutdown or some hardware issue, like bad RAM, or just a bit flip in the wrong place, it's important to always have backups of anything important.

You try the below, if it doesn't help look for a BIOS update or try using different PCIe slots if possible.
 
 

LSI is on a very old firmware, try updating, you can check if the disks are being detected in the HBA BIOS during boot, CTRL + C

Macvlan call traces are usually the result of having dockers with a custom IP address, upgrading to v6.10 and switching to ipvlan might fix it (Settings -> Docker Settings -> Docker custom network type -> ipvlan (advanced view must be enable, top right)), or see below for more info.
https://forums.unraid.net/topic/70529-650-call-traces-when-assigning-ip-address-to-docker-containers/
See also here:
https://forums.unraid.net/bug-reports/stable-releases/690691-kernel-panic-due-to-netfilter-nf_nat_setup_info-docker-static-ip-macvlan-r1356/

That look like a bug, since you're not using encryption set default filesystem to xfs (Settings -> Disk Settings)