Re: Need Help restoring a filesystem on an external drive WD 'My Book'

["Thomas Schmitt" <scdbackup@gmx.net>]

Hi,

bd wrote:
> My other similar drives mount on /dev/sdb1 or /dev/sr0...

Well, sr0 is supposed to be an optical drive: CD, DVD, BD.

sdb1 is the first partition on harddisk-like drive sdb: spinning disk,
SSD disk, USB stick, ...


> If I list my /dev directory using ls -lt, I can see what new device appears
> in the list whenever I plug my external drive. It shows 'sdb'. Not 'sdb1' as
> for other external drives, just 'sdb'.

So it looks like the partition table on the drive is unreadable or was
overwritten by data which the Linux kernel interprets as empty partition
table or as no partition table.

Do you see messages about read errors in the output of dmesg ?

----------------------------------------------------------------------------

Depending on the general readability of the device and/or on the blocks
which have been altered, it could be possible to find the filesystem start,
mount it by a loop device, or create a new partition table which lets
/dev/sd1 mark the area of the filesystem.

The main task would be to guess the start of the partition. Its end is of
less importance because one could as a make-shift set it to the end of the
device.

Looking for the signature of ext3, i read in
  https://superuser.com/questions/239088/whats-a-file-systems-magic-number-in-a-super-block
  "an ext2/ext3/ext4 filesystem always has the bytes 0x53 0xEF at positions
   1080–1081"

which is confirmed by
  http://www.nongnu.org/ext2-doc/ext2.html
  "The superblock is always located at byte offset 1024 from the beginning of
   the file, block device or partition formatted with Ext2 and later variants
   (Ext3, Ext4).
   [...]
   Table 3-3. Superblock Structure
   Offset (bytes)  Size (bytes)    Description
   56               2              s_magic
   [...]
   3.1.16. s_magic
   16bit value identifying the file system as Ext2. The value is currently
   fixed to EXT2_SUPER_MAGIC of value 0xEF53."

So one would look for bytes 0x53 0xEF at byte offset 1080 from the start
of a full block. Maybe 512-byte-block 63 is a good first guess and block 2048
the next best one. In worst case a little program would have to test a few
thousand blocks before finding a candidate for the partition start.

As soon as you have a good candidate block address, you may use a loop
device on /dev/sdb with byte offset to mount it read-only without the need
for writing a new partition table to the drive.
(See man 8 losetup, option -o.)

In case of mount success you should make a thorough backup of the filesystem
content before performing any write operation on the drive.
Only with a good backup you should then consider to try repairing the
situation.


Have a nice day :)

Thomas