Help recovering a RAID set

[Liam Proven]

On 11 May 2012 21:38, Kevin O'Gorman <kogorman at gmail.com> wrote:
> 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.

This /is/ the copy. And I have partition backups of each drive already. :¬)

> 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).

Hmm. Ta. Will do.

> If you did not have striping across separate disks, these techniques
> may work for you.

It was a 4-disk RAID5, so yes, I did.

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

:¬)

-- 
Liam Proven • Profile: http://lproven.livejournal.com/profile
Email: lproven at cix.co.uk • GMail/G+/Twitter/Flickr/Facebook: lproven
MSN: lproven at hotmail.com • Skype/AIM/Yahoo/LinkedIn: liamproven
Tel: +44 20-8685-0498 • Cell: +44 7939-087884