Re: How to salvage a degraded mdadm RAID1 with as little data loss as possible?

On 2026-06-22, Paul Leiber wrote:

>>> RAID is always before LUKS : partition > RAID array > LUKS > filesystem
>> "Is always" means for you "should always be" or "has to be"?
>>
>> As far as I understand OP, their case is the other way around (and I don't
>> see why it shouldn't be technically possible: a block device is a block
>> device is a block device, after all).
>
> Tomas' description of my setup is correct, LUKS before RAID. It has
> been working in the past, and it is working right now again. Is this
> type of setup recommended? I don't know. BTRFS doesn't show any issues
> with this setup.

So Tomas found your problem. It is at best useless to have 
partition > LUKS > RAID array > filesystem
I cannot see how it managed to work. It suppose the 2 LUKS are identical
which is a nonsense. Also a small change in data gives a bigger change in
a LUKS partition thus bigger to sync. I don't know enough about LUKS but
I suppose you loose LUKS atomicity during sync.

> However, my main suspect for the root cause of the dual-head database is
> indeed that the LUKS decryption messes with the md RAID assembly at boot,
> e. g. some timing issue or race condition. The database content doesn't change
> constantly, there are very few writes per day, so I'll rely on daily backups
> and monitor the RAID closely. There was another kernel update today, so I'll
> see what happens after a reboot, which probably was what triggered the issue
> in the past. If another issue occurs, I'll probably have a chance to find more
> information in the logs now that I know what to look for. If my assumption is
> confirmed, I'll change the order to RAID before LUKS and restore the data from
> backup. (Or I'll do it anyway out of lack of other ideas...)

You are right to suspect that. Don't wait and change it even if you can't
confirm a bug. The good and safe way is
partition > RAID array > LUKS > filesystem
And you should also improve performances.