JorgeB

You should run iperf to rule out a network issue.

Disc looks fine, I would suggest replacing/swapping both cables just to rule them out and rebuild on top.

dd/ddrescue is a bit by bit copy, including encryption. Source first, then destination.

Sorry the late replay, was away for the weekend, see here for more info:

Is the SSD passed-thought to the VM or there's a vdisk? If passed-through you should be able to mount it with UD, if a vdisk not sure what would be the best way, assuming there is one.

Just for any future reader I see like suspected this wasn't a btrfs problem: https://forums.unraid.net/topic/41333-zfs-plugin-for-unraid/?do=findComment&comment=828132

VMs usually pase when one of the storage devices is out of space/completely allocated, you can check yourself or post the diags.

Macvlan call traces are usually caused by dockers with a custom IP address.

That's it, but grabbed after starting the array, or we can't see the error.

There's a btrfs related kernel oops, it doesn't identify a specific filesystem but the docker image would be the most likely culprit, re-create it, rebooting after that's done is also a good idea.

Enable the mover logging, run it again and post new diags.

Diags posted are from last year with all disks enable.

You can still swap the SATA end with another disk, also swap power cables, if the same disk gets disable again after that there's likely a problem with it.

Yes.

Disk looks fine, might be a good idea to replace/swap cables just to rule them out if it happens again to the same disk.

It's correct now, the bug is only for pools created with older v6.7.x releases, problem is that for now they remain like that even after updating to a new release.

Don't see any issues other the already mentioned UPS communication error spamming the log.

Disk appears to have dropped offline, there's no SMART, power down, check connection and if the disk comes back online post new diags.

Yes.

Cables should be fine, I just don't know the brand, can't say if they good quality are or not, but I just know a couple of brands, so it will be the same with most. As for the LSI, it's not clear from the link posted where it comes from, new cheap LSI from China can be suspect, I usually prefer buying used server pulls from Ebay, less likely to get a fake.

There's nothing on the log, maybe the server is crashing from a hardware issue, still you can try this to see if it catches something.

Yes, I believe next Unraid release will have a warning for that, or auto-convert metadata to raid1 if data is also raid1, but not sure if it was already implemented.

Please post diags.

The important part is just above what you posted: Feb 27 15:49:48 Tower kernel: iommu ivhd0: Event logged [IOTLB_INV_TIMEOUT device=29:00.0 address=0x000000040e06b3f0] Feb 27 15:49:48 Tower kernel: ahci 0000:03:00.1: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x00000000c9000000 flags=0x0050] Feb 27 15:49:48 Tower kernel: ahci 0000:03:00.1: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x00000000c9000680 flags=0x0050] 03.00.1 is the SATA controller, it stopped responding so all devices there connected will have issues, I've seen this other times with AMD based servers, bios update might help.

Cache pool wasn't redundant because of this bug, that's very risky for a multi-device pool, if one device drops even temporarily you can lose the entire pool, unfortunately that's only visible in the diags, so I couldn't warn you sooner.