4

Something strange (don't ask) happened on my external hard-drive, resulting in (important) data being unreachable... I am failing to mount it. That data was sitting on a vfat filesystem.

I can get much of it with one tool, foremost. It sorts it into directories by file type, but I need the data intact in its original directory structure. Also, this tool gives the resulting files some random names, and is limited to a set number of file types.

It appears to me that the partition table is damaged (not sure), and I don't know how to fix it. Here's the output of gpart for the whole drive:

# gpart -vd /dev/sdb

dev(/dev/sdb) mss(512) chs(121601/255/63)(LBA) #s(1953520065) size(953867mb)
Primary partition(1)
   type: 000(0x00)(unused)
   size: 0mb #s(0) s(0-0)
   chs:  (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r
   hex:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Primary partition(2)
   type: 000(0x00)(unused)
   size: 0mb #s(0) s(0-0)
   chs:  (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r
   hex:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Primary partition(3)
   type: 131(0x83)(Linux ext2 filesystem)
   size: 947827mb #s(1941150015) s(12370050-1953520064)
   chs:  (770/0/1)-(1023/254/63)d (770/0/1)-(121600/254/63)r
   hex:  00 00 C1 02 83 FE FF FF 82 C0 BC 00 3F 99 B3 73

Primary partition(4)
   type: 000(0x00)(unused)
   size: 0mb #s(0) s(0-0)
   chs:  (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r
   hex:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

The one parition I'm interested in is one that's claimed to be Linux ext2 filesystem. That can't be accurate from my knowledge (it was vfat, but it could also have been NTFS, who knows). It also, that can't be accurate, according to another output of gpart (should I trust it?), this time specifying just that partition:

# gpart -vd /dev/sdb3

dev(/dev/sdb3) mss(512) chs(120831/255/63)(LBA) #s(1941150015) size(947827mb)

* Warning: strange partition table magic 0x606B.
Primary partition(1)
   type: 031(0x1F)(UNKNOWN)
   size: 522639mb #s(1070366139) s(4182104394-5252470532)
   chs:  (961/156/44)-(97/173/28)d (260323/244/28)-(59601/209/5)r
   hex:  F7 9C EC C1 1F AD 1C 61 4A D9 45 F9 BB 7D CC 3F

Primary partition(2)
   type: 249(0xF9)(UNKNOWN)
   size: 47812mb #s(97919955) s(4081875516-4179795470)
   chs:  (993/11/62)-(249/64/22)d (254084/254/55)-(260180/59/54)r
   hex:  D4 0B FE E1 F9 40 16 F9 3C 7A 4C F3 D3 23 D6 05

Primary partition(3)
   type: 211(0xD3)(UNKNOWN)
   size: 711401mb #s(1456950127) s(4249722057-5706672183)
   chs:  (671/191/48)-(644/231/52)d (264532/245/43)-(87874/144/6)r
   hex:  63 BF B0 9F D3 E7 B4 84 C9 9C 4D FD 6F 4B D7 56

Primary partition(4)
   type: 089(0x59)(UNKNOWN)
   size: 715318mb #s(1464971513) s(1293543745-2758515257)
   chs:  (1003/227/11)-(789/19/55)d (80519/95/26)-(171709/161/30)r
   hex:  43 E3 CB EB 59 13 F7 15 41 E9 19 4D F9 B0 51 57
Community
  • 1
tshepang
  • 65,642
  • I am running out of ideas recovering this data, so if anyone cares about rep, I got a Bounty... – tshepang Jun 13 '11 at 09:48
  • 1
    Recovering a damaged filesystem structure is hard. I won't say it's impossible, but it's a lot more difficult than recovering files with known signatures (e.g. text files, images, …) as suggested in your previous thread. – Gilles 'SO- stop being evil' Jun 13 '11 at 21:51

2 Answers2

1

Do you think its a partition boundry issue, or do you know the disk has hardware errors?

Some things to try:

  • Copy (dd) the partition contents to somewhere and then change the partition type back to Vfat/NTFS
  • Try different FS mount options, etc.
  • Restore from a copy of the original partition layout (maybe from an old anaconda install log, etc.)
Michael Mrozek
  • 93,103
  • 40
  • 240
  • 233
AndyM
  • 514
  • I think the hard drive is in good condition because I was able to perform a dd of the entire 900GB+ partition to another hard drive. I also tried multiple -t mount options. – tshepang Jul 13 '11 at 14:09
0

Use dd or ddrescue (or dd_rescue) to image the failing drive if you have sufficient space on another one for it. If the original drive has a hardware error, then it's good to have a master copy. You might also be able to mount (a copy of) the master image as a block device (loopback with 'mount -o'?).

tshepang
  • 65,642
Not Sure
  • 466
  • 2
  • 3
  • You probably meant this kinda command: sudo mount /dev/sdb3 temp -t vfat -o loop=/dev/loop0. It gives me the same errors as if I had mounted it normally. See the full story here. – tshepang Jun 13 '11 at 13:55
  • I tried dd, drescue and dd_rescue already, and it's all confusing. They report no errors and for the tool that does the actual copying (I don't remember which), the results are the same as the original (i.e. unmountable filesystem). Well, unless I don't know how to use them. – tshepang Jun 13 '11 at 13:58
  • 1
    @Tshepang: dd_rescue and friends are for pulling data off a dying hard drive. They won't help you here, since you have a damaged filesystem structure but are able to read each byte of it without trouble. – Gilles 'SO- stop being evil' Jun 13 '11 at 21:50
  • 1
    @Gilles: That's correct. @Tshepang: since you didn't mention the particulars of how this happened, I assumed that a hardware error could be involved. Even if not, you should retain an image of it to roll back to if an attempted solution does not work out. – Not Sure Jun 20 '11 at 21:25
  • @Tshepang (first comment): I was hoping there is a way to expose the entire drive image as a single device, then do some magic, then attempt to mount a single partition from it. I'm sorry I couldn't be of any real help. Good luck! – Not Sure Jun 20 '11 at 21:29
  • @NotSure There is a way (check out losetup), but it's not going to help Tshepang unless he finds the start of a valid filesystem. Right now there isn't a valid filesystem on the partition, so recovering pieces is the best bet. – Gilles 'SO- stop being evil' Jun 20 '11 at 21:33