Btrfs keeps getting corrupted

[Roman Mamedov <rm@romanrm.net>]

Hello,

I have a Btrfs filesystem that keeps getting corrupted for some reason.

The setup is a 4-disk external enclosure connected via USB3. It is powered-on
and off as needed.

In it there's one 12TB Seagate Exos HDD, that admittedly has a low number of 
reallocated sectors, but there are no IO errors at any time during the
operartion (so those do not seem to be hit and there are no new ones).

On the HDD there's a LUKS partition, and inside LUKS there's a Btrfs
filesystem.

The workflow is power-on, luks-open, mount, rsync, unmount, luks-close,
power-off.

On the previous attempt to use this, the FS was starting to go read-only on
accessing some recently-copied files, and there were "transid verify failed"
errors in dmesg. I wrote that off as perhaps not syncing, unmounting and
closing everything off correctly before power-off.

Modified my scripts to do a "sync" before every step in the power-off
sequence. Reformatted from scratch, copied all data again, and turned it off.

Next time, a few weeks later, I try to do another rsync, and this time it
doesn't even mount:

[248942.223437] BTRFS: device label sea12.k4e devid 1 transid 725 /dev/dm-26 scanned by (udev-worker) (5328)
[248942.267427] BTRFS info (device dm-26): first mount of filesystem 4071aeab-ccab-4b36-901f-38fd38e4ef41
[248942.267441] BTRFS info (device dm-26): using crc32c (crc32c-intel) checksum algorithm
[248942.267446] BTRFS info (device dm-26): use zstd compression, level 3
[248942.267448] BTRFS info (device dm-26): using free space tree
[248942.358145] BTRFS error (device dm-26): level verify failed on logical 1053650288640 mirror 1 wanted 3 found 0
[248942.388148] BTRFS error (device dm-26): level verify failed on logical 1053650288640 mirror 2 wanted 3 found 0
[248942.396897] BTRFS error (device dm-26: state C): failed to load root csum
[248942.408461] BTRFS error (device dm-26: state C): open_ctree failed

btrfsck:

Opening filesystem to check...
parent transid verify failed on 1053650288640 wanted 723 found 110
parent transid verify failed on 1053650288640 wanted 723 found 110
parent transid verify failed on 1053650288640 wanted 723 found 110
Ignoring transid failure
ERROR: root [7 0] level 0 does not match 3

ERROR: could not setup csum tree
ERROR: cannot open file system

===

Such a high disparity in transid mismatch, flush is not working somewhere? But
I specifically do "sync" even multiple times now, before unmounting and after.

How can I figure out what is to blame here, is it the enclosure, is it USB,
LUKS, Btrfs, or some fundamental bug involving a combination of these?

Or maybe the drive is faulty in some mysterious way and storing/returning old
data instead of IO errors or sector reallocation.

-- 
With respect,
Roman