FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Ubuntu > Ubuntu User

 
 
LinkBack Thread Tools
 
Old 05-10-2012, 07:47 PM
Liam Proven
 
Default Help recovering a RAID set

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

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

--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
 
Old 05-10-2012, 08:56 PM
Rashkae
 
Default Help recovering a RAID set

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.




--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
 
Old 05-10-2012, 09:30 PM
Liam Proven
 
Default Help recovering a RAID set

On 10 May 2012 21:56, Rashkae <ubuntu@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.


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

--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
 
Old 05-11-2012, 07:14 PM
Rashkae
 
Default Help recovering a RAID set

On 05/10/2012 05:30 PM, Liam Proven wrote:

On 10 May 2012 21:56, Rashkae<ubuntu@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.




Sorry I can't offer any real help, but depending on how important this
data is to you, I would say, your bet would be to contact Red Hat and
say you really need some of that premium Linux engineer support they offer.


However, if I was tasked with doing something like this myself, I would
probably try something like this.


1. dump your current partitions into files.

2. On a new drive, zero it completely, then use madm to create a new
raid array on a new blank partition. I wold then examine this parition
to see exactly where the superblock is located at the end of the
partition. Maybe someone on mdadm or LKML support can help you in this
regard instead of trying to find it yourself.


3. Find this same superblock the files created earlier, and trim the
end of the file so the mdadm superblock is in the correct offset from
the end of the file.


4. Map the files to loopback devices.

5. try to coax mdadm to recognize the array and assemble it.


--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
 
Old 05-11-2012, 08:38 PM
"Kevin O'Gorman"
 
Default Help recovering a RAID set

On Thu, May 10, 2012 at 2:30 PM, Liam Proven <lproven@gmail.com> wrote:
> On 10 May 2012 21:56, Rashkae <ubuntu@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

--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
 
Old 05-14-2012, 06:25 PM
Liam Proven
 
Default Help recovering a RAID set

On 11 May 2012 21:38, Kevin O'Gorman <kogorman@gmail.com> wrote:
> On Thu, May 10, 2012 at 2:30 PM, Liam Proven <lproven@gmail.com> wrote:
>> On 10 May 2012 21:56, Rashkae <ubuntu@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@cix.co.uk • GMail/G+/Twitter/Flickr/Facebook: lproven
MSN: lproven@hotmail.com • Skype/AIM/Yahoo/LinkedIn: liamproven
Tel: +44 20-8685-0498 • Cell: +44 7939-087884

--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
 

Thread Tools




All times are GMT. The time now is 10:36 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org