Can't repair super block, bad magic number

Hello all,

I have a hard drive that I can't repair.
The drive is WD15EARS - Filesystem ext4 ( not 100% sure )
It's used in a Synology DS110j NAS.

I try to run fsck -p /dev/sdb on the HD and I get this:

Bad magic number in super-block while trying to open /dev/sdb
/dev/sdb:
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem ( and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
   e2fsck -b 8193 <device>

Next I get the superblocks with mkfs -n /dev/sdb

It outputs 18 blocks, tried them all with fsck -b and all returned this error:

fsck 1.39 (29-May-2006)
e2fsck 1.39 (29-May-2006)
fsck.ext2: Bad magic number in super-block while trying to open /dev/sdb

The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem ( and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
   e2fsck -b 8193 <device>

Now I believe the HD has a ext4 fs, I couldn't find any info from the disk it self, but read it from the Synology website.

The OS I'm using is CentOS 5.7 and Ubuntu server 10.04. I also have Windows 7 & XP and Mac 10.6.8 to use as well.

I noticed that CentOS fsck goes up to fsck.ext3 and Ubuntu goes up to fsck.ext4, but both produced the same result.

Well, I'm at a loss here... Any help will be greatly appreciated.

Thank you all.

Somehow I don't think they created the filesystem on the whole disk, without any partition information. What does the output of fdisk -l /dev/sdb show?

Thanks pludi
it shows

Disk /dev/sdb: 1500.3 GB, 1500301910016 bytes
255 heads, 63 sectors/track, 182401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Disk /dev/sdb doesn't contain a valid partition table

---------- Post updated at 09:46 PM ---------- Previous update was at 07:21 PM ----------

Extra info...
Ran fdisk -l in Ubuntu and it returned 2 extra lines...

I/O size (minimun/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

---------- Post updated at 10:03 PM ---------- Previous update was at 09:46 PM ----------

Oh, just to let you know, the OS is based on Linux kernel 2.6 GPL Linux.
The system (NAS) was running for about a year before this happened.

I came across one thread on another website that another person having a similar problem was suggested to try vgscan from the lvm2 package, I'm not sure what that is, but thought I'd add it.

That's actually a good hint. Run pvscan (scan for physical volumes with a matching identification), vgscan (search for volume groups on known PVs), and then vgdisplay (show information about known volume groups).

Background: LVM is the logical volume manager used in Linux. What it basically does is collect physical disks into larger volume groups, from which logical volumes can be carved. These behave, as far as the filesystem and up is concerned, like partitions, but are easier to extend and can be given meaningful names.

I ran the three and returned this:

# pvscan
No matching physical volumes found.
# vgscan
Reading all physical volumes. This may take a while...
# vgdisplay

I came across a program called TestDisk, its used to repair partition tables.
I haven't used it yet since it wants to know which partition table the drive uses and I'm not sure. It looks like it analyzes first, then if it finds any, it can make the repairs.

TestDisk - Official

TestDisk - In use
geekyprojects.com/storage/how-to-repair-a-damaged-partition-table-or-mbr/

Should I use that since lvm didn't return any thing?