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

Am 22.06.26 um 09:35 schrieb [email protected]:
> On Mon, Jun 22, 2026 at 08:18:45AM +0200, Michel Verdier wrote:
>> On 2026-06-22, [email protected] wrote:
>>
>>>> Your commands are strange : the partitions should be the disk partitions
>>>> from /dev and not mapped ones. Or you have another layer ? From where
>>>> come /dev/mapper/partition_1 and /dev/mapper/partition_2 ?
>>> If I have been following along, the RAID parts are LUKS encrypted devices,
>>> so to me it does make sense.
>> 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.

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...)