Re: RAID array is gone, please help

[Stephen Mueller]

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@xxxxxxxxxxx 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.