fsck --> Bad Super Block: Magic Number Wrong

[rewt]

Hi folks. I need some help with a problem I'm having with a filesystem that I am unable to mount. The filesystem sits on /dev/vg02/lvol1 on /dev/dsk/c3t1d0.
When I attempt to fsck /dev/vg02/lvol1 I receive endless messages that look like this:
837491030 BAD I=13.
All with different inode numbers.
When I fsck /dev/dsk/c3t1d0 I receive the error message:
BAD SUPER BLOCK: MAGIC NUMBER WRONG
I went and found the /var/adm/sbtab to look for alternate superblocks. In this file there are only superblocks listed for /dev/vg02/lvol1 and not for the physical disk. So I attempt to fsck -b# /dev/vg02/lvol1 trying different numbers listed as alternate superblocks in the sbtab but I still get the same scrolling error messages that I received when first attempting to fsck it.
The problem here is that this volume group is the one that contains my backup software so I am hosed. Has anyone successfully been able to use an alternate superblock or am I possibly doing something wrong? I am trying to avoid the painful last resort of reloading my backup software and redoing all of the backups.
Thanks.

[John Palmer]

Hi,

You must specify the volume name to fsck, the /dev/dsk device will not work.
hfs:
fsck -F hfs /dev/vg01/rlvol1

vxfs:-
fsck -F vxfs /dev/vg01/rlvol1

Is this a hfs filesystem? The entry in /var/adm/sbtab may be old if the filesystem was recreated as vxfs.

What happened to it to stop it mounting?

If the above fsck commands fail then I'm afraid that you'll have to recreate the filesystem and restore.

Regards,
John

[Pedro Sousa]

Just another hint...
If it is a vxfs FS, you can check it totally by doing:
fsck -F vxfs -o full /dev/vgxx/rlvolx

good luck!

[rewt]

Unfortunately it is HFS. It is looking like I will have to reformat and restore. :/

[Jeganathan Venkitasamy]

Hi,

In my experience, I usually see block 32 as first alternate super block. Why don't you give a try by using " -o b=32" option?
Afterall it is not going to destroy anything.
you may save time in reformating and restoring data.

Regards,
Jegi,
NBC

[melvyn burnard]

firstly,ensure you are using the raw device, i.e. /dev/vg02/rlvol2

secondly are you sure it is HFS? if so, there is ALWAYS a spare superblock at 16, so try fsck -F hfs -b 16 /dev/vg02/rlvol2

failing that, I am not sure there is much more to do

[Philip Chan_1]

Just a reminder, make sure that raw device isn't managed by RDBMS. Some database servers, like Sybase, manage raw partitions on their own therefore the magic numbers will report as wrong during fsck checks.

[Nick W]

Before you get into re-creating your filesystem, try mounting it READ-ONLY.
- if that works, you have a chance to recover/copy your data (obviously, some will be gone....)
I have used this technique successfully in the past on other (SVR4) OS, but I have not tried it on HP systems - but it won't do any harm....

Nick