Is your BBU okay? These are also checked periodically, and if they fail that disables all write caches.

FWIW I've been running a build server for five years and it only made a 4% dent in the wear indicator, despite the SSDs being the bottleneck for most of the time.

FWIW 845 Mbps is already suspiciously low. I mean, I collect old PCs, and everything built in the last ten years can saturate an 1 Gbps link with no trouble.

Exactly -- I have lots of data in the RAID6 anyway, and I've set up a small volume to follow the SSD. The (battery backed) write cache makes the scattered write performance bearable, and I can hot-swap the SSD when it fails.

I think of it the other way round: the SSD is the main drive, and the RAID6 volume is the backup in case the SSD dies.

Another useful configuration on Linux is a software RAID1 between an SSD and a RAID6 volume, with the --write-mostly flag applied to the RAID6, this gives you the performance of the SSD, but you still have very good fault tolerance.

Is this already a copy? If so, this is a dangerous situation, because both PVs now have the same UUID.

I mean, both sdb3 and sdc3 have a PV on them, which is assigned to a volume group, and there are about 100 GB used on each and less than 100 GB free, so there isn't enough free space to keep all the data on just one. The dd command you suggested would overwrite the contents of one PV with that of the other, destroying data in the process. You need an additional storage medium with enough space. I think you should be able to use LVM to copy the data, which would solve the size difference problem, but I'm not entirely sure how it reacts to being unable to update metadata.

That pvscan output suggests that both SSDs are in use already. Copying one over the other would be a bad idea then.

I use a gpg authentication subkey as an ssh key through gpg-agent

Anything that calculates an average over a fixed amount of time and records it.

The error message suggests checking the BIOS settings -- VT-d must be enabled.