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

On Sat, 20 Jun 2026 18:01:15 +0200
Paul Leiber <[email protected]> wrote:

> Somehow, I missed to include the RAID1 information for md0 to the
> configuration file (e. g. by entering root@localhost:~# mdadm
> --detail --scan /dev/md0 >> /etc/mdadm/mdadm.conf). I am not sure if
> this actually is the cause and adding that information would solve
> the issue.
> My questions are the following:
> 
> 1. Is my analysis valid in principle? Especially: Could the root
> cause for this issue be that mdadm.conf is missing the information
> for md0, and could adding that information prevent data loss or
> inconsistencies in the future?

I doubt that this is the culprit. the man page for mdadm says, in part:

     Assemble
              Assemble the components of a previously created array
     into an active array.  Components can be explicitly given or can
     be searched for.  mdadm checks  that  the components do form a
     bona fide array, and can, on request, fiddle superblock
     information so as to assemble a faulty array.

So mdadm *should* find both devices. But it might not be. And adding
that line will not hurt. I have a similar line in my mdadm.conf.

I built my RAID array up a bit differently that you did yours. You made
your partitions, put LUKS on the partitions, then the RAID on top of
that. I have the partitions, then the RAID array, LUKS on top of that,
then LVM, with file systems on top of the LVs. But I know of no reason
your setup shouldn't work.

I have found that when I have multiple LUKS partitions, giving them
all the same passphrase means I need give only one passphrase to
decrypt on boot.

> 2. Can I (re)create the RAID1 md0 or (re-)add the missing partition
> in an easy way that no or at least not all information is lost? If
> yes, how?

Yes. For the gory details see
https://oneuptime.com/blog/post/2026-03-02-how-to-replace-a-failed-disk-in-mdadm-raid-on-ubuntu/view.

In short,

* Fail the offending disk. It looks like this has already happened, but
  it shouldn't hurt to do it again.

* Remove the disk from the array.

* Add the disk back in again. This should trigger rebuilding, which
  takes a while. During the rebuild, the data should be both readable
  and writable. You may monitor with:

  cat /proc/mdstat