Help recovering a RAID set

Kevin O'Gorman kogorman at gmail.com
Fri May 11 20:38:56 UTC 2012


On Thu, May 10, 2012 at 2:30 PM, Liam Proven <lproven at gmail.com> wrote:
> On 10 May 2012 21:56, Rashkae <ubuntu at tigershaunt.com> wrote:
>> On 05/10/2012 03:47 PM, Liam Proven wrote:
>>>
>>> The RAID in one of my servers died. Sadly, so did the disk with the
>>> backup on it when I tried to recover it. As did the disk in my desktop
>>> with another backup of all the important files.
>>>
>>> So, I am trying to recover the data.
>>>
>>> I used gddrescue to get image copies of the 4 × 40GB drives; they are
>>> on a 300GB drive, as partitions sdb5, sdb6, sdb7 and sdb8.
>>>
>>> I am trying to assemble them with mdadm but it reports that there's no
>>> superblock on any of them.
>>>
>>> Looking at the raw partitions with a hex editor, I can see that there
>>> are large slices of empty space at the start of each drive.
>>>
>>> On sdb5 and sdb6, the data starts at 0xB0000. On sdb7 and sdb8 it
>>> starts at 0xAA000.
>>>
>>> Can anyone suggest how I can prune off the first  720896 bytes of the
>>> first 2 partitions and the first 696320 bytes of the second 2?
>>>
>>> I have other spare drives - I could in principle `dd` the whole
>>> partitions onto other media, but I am not fluent enough in dd to skip
>>> the first $number blocks...
>>>
>>
>> The version of mdadm that your array was created on probably used the
>> superblocks that are store at the end of the device, not the start.  If
>> these new paritions aren't exactly the same size as the original hard drives
>> (or partitions therefof), that's why mdadm can't find the superblocks.
>> I've never recovered a raid array from such a situation, but I would think
>> the best thing to do would be the dump the partitions from the original
>> drives into a file rather than a new partition.
>
> One of the 3 working drives has since failed completely. This is now
> the only remaining copy of the data.

First, the most important thing is back up your only copy.  Don't get
fancy -- copy the whole drive.  If you don't have a place to put it,
unmount the drive and go buy something big enough, then take the
backup before that drive is at any further risk.  It's probably best
to not power it off for any extended period, and not at all if
possible, but do anything else you can to avoid further lossage.  With
a copy in place, you can try other things.

I was faced with something like this very recently, except that I lost
the controller and the drives were okay.  Since it was hardware RAID
that did not start at the beginning of any volume, I had trouble
finding the partitions.  I wrote my own program to look for the
signature of a partition table -- *not* the filesystem on it -- and
found where the RAID volume was, and dd-ed the whole volume with its
several partitions and filesystems to the start of a new large-enough
drive.  Then the whole thing quickly was recognizable to the regular
non-RAID software, and normal recovery was possible.

I understand that there's already software to find partitions and link
them into the normal arrangement of a drive.  I didn't know that at
the time.  Check out the 'rescue' command of non-GUI parted(8).

If you did not have striping across separate disks, these techniques
may work for you.  I can help with dd, which I've been using forever.

Once again, first priority is to make sure the data won't get lost.
Protect it from fumble-fingers, that jerk Murphy, and everything.

-- 
Kevin O'Gorman, PhD




More information about the ubuntu-users mailing list