On Assembled RAID the header is identical to sdb. However if RAID gets created with wrong order of devices ( sda or sdb as first device, via mdadm --create ) the header of sdc is always identical with header of Assembled RAID ( Offset Data = FB 1B FB 1B).
I confirm that the strange data I discovered is not part of the LUKS header. According to LUKS documentation, only keyslot 8 information should be stored at this offset. Since I never added any keys to keyslot 8, the corrupted data must have been written by someone else. As the mdadm checksums show that the partitions are correct, I believe the issue was caused by faulty mdadm operations.
I have temporarily modified the corrupted sectors using data from the working drive. After reinitializing mdadm, I am now able to open the LUKS volume. I will recover my data and rebuild a new Btrfs RAID without using mdadm.
Thank you all for your contributions to this discussion!
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.