Re: Need help Recover raid5 array

[Andreas Klauer <Andreas.Klauer@metamorpher.de>]

On Sat, Dec 18, 2021 at 11:31:39PM -0500, Tony Bush wrote:
> I forgot that this new-to-this-system SSD had Windows 10 OS on
> it and I believe it tried to boot while I was working on hooking up my
> monitor.  So I think that it saw my raid drives and tried to fdisk
> them.  I did mdadm directly to drive and not to a partition(big
> mistake I know now).  So I think the drives were seen as corrupted and
> fdisk corrected the formatting.

Windows is known to do this but it can just as well happen within Linux.
Hopefully no filesystem formatting took place...

> To fix, I have been leaning toward making the drives ready only and
> using an overlay file. Like here:
> https://raid.wiki.kernel.org/index.php/Recovering_a_failed_software_RAID#Making_the_harddisks_read-only_using_an_overlay_file

This method is so useful there should be standard command in Linux 
to create and manage overlays; but there is none so you have to make do 
with the 'overlay manipulation functions' as shown in the wiki.

> But i dont understand all the commands well enough to work this for my
> situation.  Seems like since I don't know the original drive
> arrangement that may be adding an additional level of complexity.  If
> I can figure out the read only and overlay, I still don't know exactly
> the right way to proceed on the mdadm front.  Please anyone who has a
> handle on a situation like this, let me know what I should do.  Thanks

I summarized `mdadm --create` for data recovery here:

  https://unix.stackexchange.com/a/131927/30851

In addition you should remove the bogus GPT and MBR partition headers. 
You can use 'wipefs' for this task. (Test it with overlays first...)

  wipefs --all --types pmbr,gpt,dos /dev/...

You are lucky to have all the relevant `mdadm --examine` output, 
so you already know the correct data offset and only need to guess 
the correct order of drives.

Regards
Andreas Klauer