Server Disk Problem

[Daniel Feiglin]

Hi folks!

Here we go:

In addition to posting this query, I found and downloaded a short LVM
Howto. In addition, I used a live openSUSE 11.3 CD. Following the Howto,
I was able to discern that:

1. The server had two LVM volumes on two separate physical drives
configured for RAID 1.
2. They showed as /dev/sda and /dev/sdb.
3. After going through the Howto instructions, I was able to demonstrate
that sda was corrupted and unmountable as an LVM drive but sdb was OK,
and I was able to get into it and copy data to a disk on key.

If anyone is interested, I will prepare a log of the procedure and post
it. At this point I am using the LVM instructions as a bit of a parrot,
but that looks likely to change for the better. :)

Thanks for your response,


Daniel

P.S. If anyone is wondering, "why openSUSE and not ...?", please note
that I have been a SUSE user since 1999 and I'm too lazy to change. In
any event, 11.3 seems to be a good release.


On 07/28/2010 12:46 AM, Amos Shapira wrote:
> On 28 July 2010 06:37, Etzion Bar-Noy <ezaton at tournament.org.il> wrote:
>   
>> As I have said - if he could mount it, he can read the superblock.
>>     
> I missed the "mounted" part, only that he is looking for a secondary superblock.
>
> Still:
> 1. If he's still looking for a secondary superblock (as fsck
> recommend) then that tool can help him achieve that.
> 2. If he wants to try to salvage the files to another disk then this
> tool can help there too.
>
> --Amos
>
>   
>> Ez
>>
>> On Tue, Jul 27, 2010 at 3:50 AM, Amos Shapira <amos.shapira at gmail.com>
>> wrote:
>>     
>>> 2010/7/27 Etzion Bar-Noy <ezaton at tournament.org.il>
>>>       
>>>> Are you checking the correct device?
>>>> If fsck.ext3 can't find superblock, the system could not have mounted
>>>> the device to begin with.
>>>> Please post the results of
>>>> lvm lvs
>>>> cat /etc/fstab (if available)
>>>> Thanks
>>>> Ez
>>>>         
>>> Here is a method using testdisk to find the backup superblocks:
>>> http://www.cgsecurity.org/wiki/Advanced_Find_ext2_ext3_Backup_SuperBlock
>>>
>>> (never tried this).
>>>
>>> --Amos
>>>
>>>       
>>>> 2010/7/26 Daniel Feiglin <dilogsys at inter.net.il>
>>>>         
>>>>> Hello folks!
>>>>>
>>>>> I am trying to assist in the following situation:
>>>>>
>>>>> The user has a 1u IBM "Pizza" server. It was configured as one
>>>>> partition
>>>>> (ext3) and loaded with Centos something-or-other, with the partition
>>>>> set
>>>>> up as a single LVM volume (yes, including the root directory).
>>>>>
>>>>> One fine day, after a reboot, it ran fsck which conked out after
>>>>> checking about 12% of the disk advising to run fsck manually. At that
>>>>> point, we logged in as root, and ran fsck -n /dev/whatever to see
>>>>> what's
>>>>> happening.
>>>>>
>>>>> The latter yielded the dreaded corrupt super block, try the next one
>>>>> (8193). That (as I kind of expected) didn't work either.
>>>>>
>>>>> >From being root I can "see" the various directories an even cd to
>>>>> them.
>>>>> I am aware  that it means little if their contents are corrupted.
>>>>>
>>>>> Question:
>>>>>
>>>>> 1. Are there any recovery tools for this kind of situation?
>>>>> 2. Is my only choice, to install another pre-partitioned hard disk, log
>>>>> in with (say) a "live" CD, mount the corrupt disk and try to manually
>>>>> copy my data directories?
>>>>>
>>>>> Regards,
>>>>>
>>>>>
>>>>> Daniel
>>>>>
>>>>> _______________________________________________
>>>>> Linux-il mailing list
>>>>> Linux-il at cs.huji.ac.il
>>>>> http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
>>>>>
>>>>>           
>>>>
>>>> _______________________________________________
>>>> Linux-il mailing list
>>>> Linux-il at cs.huji.ac.il
>>>> http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
>>>>
>>>>         
>>
>>     
>   
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dilogsys.vcf
Type: text/x-vcard
Size: 297 bytes
Desc: not available
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20100728/2f6f7a11/attachment.vcf>