Re: RAID array is gone, please help

[Stephen Mueller <stephen@mueller.org>]

Apologies, I should have started this on linux-raid...


stephen@fred> sudo gdisk -l /dev/sdc
GPT fdisk (gdisk) version 1.0.1

Partition table scan:
   MBR: protective
   BSD: not present
   APM: not present
   GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sdc: 7814037168 sectors, 3.6 TiB
Logical sector size: 512 bytes
Disk identifier (GUID): 60F1D54C-9D17-4688-BD6E-447F5E7408EB
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 7814037134
Partitions will be aligned on 2048-sector boundaries
Total free space is 7814037101 sectors (3.6 TiB)

Number  Start (sector)    End (sector)  Size       Code  Name
stephen@fred>

The other disks are all similar.

How do I remove the MBR/GPT tables? So you would do that, and then the
mdadm --create?

Thank you.

On 3/23/2017 20:27, Lennart Sorensen wrote:
> On Thu, Mar 23, 2017 at 07:09:41PM +0100, raid@mueller.org wrote:
>> Thank you very much or your reply.
>>
>> I naively thought that starting without partitions would be the best
>> starting point, given 3 of the disks had been in a RAID5 array
>> previously (possibly with partitions, not sure), but that looks like
>> a bad choice, based on some other things I've googled. Lesson learned.
>>
>> I have an mdadm.conf file, but it could be a remnant of my previous array.
>> I've already edited it trying to get things to work, so I'm
>> not sure if it was updated when I created the new array or not.
>>
>> I see various people online have had success in my situation using
>> madadm --create /dev/md0 --assume-clean --verbose --level=10 \
>> --raid-devices=4 /dev/sdc /dev/sdd /dev/sde /dev/sdf
>>
>> Some people used --assume-clean, and some didn't. Given my array wasn't done
>> with its resync, maybe I should leave that out.
>>
>> If that would work, I guess then I need to get the data off the array,
>> delete it, and recreate it with disk partitions, or risk this happening
>> again at the next reboot, for whatever reason.
>>
>> Anyone think it's a bad idea to try mdadm --create at this point?
>>
>> Sorry, I'm not sure how to write 0's to sector 0...
>
> Well the other possibility is that by having a MBR saying this has GPT and
> probably having mdadm corrupt the GPT by writing to 4k in, but nothing
> overwriting the backup GPT at the end of the device, something may have
> restored the GPT to the original location, even if it was an empty GPT,
> in which case your superblock is likely overwritten.
>
> Does 'gdisk -l /dev/sdc' claim that it is a valid GPT table or corrupt?
>
> So if that is what happened (not sure what would have done it, although
> it seems badly defined who is responsible for fixing the GPT if it is
> detected that the backup is valid but the primary is corrupt), then you
> will want to make sure the MBR and GPT tables are removed, before you
> do anything else.  Likely the data is still there, since I think the
> first data block is offset a bit into the device, and the GPT is only
> the first 32KB or so of the device.  If that is the case, doing the
> create would probably work.  Of course the safest thing to do would be
> to clone your disks before trying to reassemble them (which means you
> need another four 4TB drives, but if the data is important, that's
> probably worth it).
>
> Of course you would also have to be sure the mdadm command you use to
> create it again is exactly the same as before, and that the device names
> are exactly the same as before.
>