# Data recovery...

## jeanfrancis

Hi there!

So... I was backing data up in order to do a fresh Gentoo install.. 

I was moving data from my /home/user, on a external USB hard drive...

Only one thing was remaining, a virtual hard drive where XP stays... ~8-10 GB... I start the move, and it fails (IO Error)...

I then realize that... this HD was a FAT32   :Shocked: 

Now the files on the HD are renamed with DOS format (truncated, adding ~1, ~2, ...). And I get IO error while reading:

```

# ls

ls: cannot access backup~3: Input/output error

backup~1  backup~2  backup~3 

```

And in dmesg:

```

sd 2:0:0:0: Attached scsi disk sdb

sd 2:0:0:0: Attached scsi generic sg2 type 0

usb-storage: device scan complete

sd 2:0:0:0: SCSI error: return code = 0x08000002

sdb: Current: sense key: Medium Error

    Additional sense: Unrecovered read error

end_request: I/O error, dev sdb, sector 512

Buffer I/O error on device sdb, logical block 64

end_request: I/O error, dev sdb, sector 512

Buffer I/O error on device sdb, logical block 64

sd 2:0:0:0: SCSI error: return code = 0x08000002

sdb: Current: sense key: Medium Error

    Additional sense: Unrecovered read error

end_request: I/O error, dev sdb, sector 65

Buffer I/O error on device sdb1, logical block 1

Buffer I/O error on device sdb1, logical block 2

Buffer I/O error on device sdb1, logical block 3

Buffer I/O error on device sdb1, logical block 4

Buffer I/O error on device sdb1, logical block 5

Buffer I/O error on device sdb1, logical block 6

Buffer I/O error on device sdb1, logical block 7

Buffer I/O error on device sdb1, logical block 8

Buffer I/O error on device sdb1, logical block 9

Buffer I/O error on device sdb1, logical block 10

FAT: Filesystem panic (dev sdb1)

    fat_get_cluster: invalid cluster chain (i_pos 0)

    File system has been set read-only

FAT: Filesystem panic (dev sdb1)

    fat_get_cluster: invalid cluster chain (i_pos 0)

FAT: Filesystem panic (dev sdb1)

    fat_get_cluster: invalid cluster chain (i_pos 0)

```

Data in other directories seems okay...

Anybody know a tool that would help me recover my files ?...

Thanks in advance !!

----------

## NeddySeagoon

jeanfrancis,

FAT32 provides both DOS file names and long file names. It looks like you have it mounted to show DOS names.

Ensure the filesystem type is set to vfat and not dos at mount.

----------

## jeanfrancis

Hi !

Thanks for the answer.

You are right, the HD was mounted in dos. However, it was automatically mounted in vfat in the past. Here is the new output:

```

usb # ls

ls: cannot access backup_gentoo: Input/output error

backup_gentoo  backup_hdMaxtor  backup_win 

```

Same kind of errors in dmesg:

```

FAT: Filesystem panic (dev sdb1)

    fat_get_cluster: invalid cluster chain (i_pos 0)

```

I can read the disk, but not the backup_gentoo folder  :Sad:  .... Any other idea ?

----------

## NeddySeagoon

jeanfrancis,

If the backup was made with the filesystem mounted as -t dos, long filenames will not have been stored. However, filename translation will have been carried out to filena~1 ... filena~2 to preserve unique filenames.

There is no way to recover the long names short of looking at the files.

It looks like the top level directory structure has become corrupt, as you are able to mount the partition. 

Can you make an image of the directory with dd ?

That would confirm the issue is data structures and not the drive surface.

----------

## jeanfrancis

Hi !

The HD was mounted as vfat while moving.

I'll test the dd tonight (1 pm here).

I never used it but it should not be complicated  :Smile: 

----------

## jeanfrancis

```

# dd if=/mnt/usb/backup_gentoo of=backup

dd: opening `/mnt/usb/backup_gentoo': Input/output error

```

I don't know if I use dd the right way... However, backup_gentoo is a directory but dd don't warn me about it...

----------

## jeanfrancis

```

# dd if=/dev/sdb1 of=backup

dd: reading `/dev/sdb1': Input/output error

88+0 records in

88+0 records out

45056 bytes (45 kB) copied, 7.38265 s, 6.1 kB/s

```

 :Sad: 

----------

## NeddySeagoon

jeanfrancis,

You have a problem with the drive surface or the data on it 89 blocks (1 block is 512 bytes) from the start of /dev/sdb1.

Exactly what that means for your data depends on what is stored there, which is filesystem dependant. you don't yet know how far it extends.

For FAT32, its close to the beginning of the first copy of the File Allocation Table.

Do not attempt recovery in position. Read about dd_rhelp then use it to make a copy of the partiton to a file.

After you have a copy of all the data that can be read, you can try fsck on the damaged partition. If you are lucky, it will fix the problem. If not, it may make things worse. Hence the backup.

----------

## jeanfrancis

```

  * All versions of 'sys-fs/dd-rhelp' are masked. Candidates are:

    * sys-fs/dd-rhelp-0.0.6::gentoo: Masked by keyword ( ~mips ~x86 )

```

That's unfortunate....

Edit: ~amd64 here... I already tried dd-rescue, and it was copying things very slowly... but I don't have enough place to copy the whole disk, it's a 80 GB and I don't have any 80GB free space on a single partition...

----------

## mudrii

use tar bzip2 or gz to compress and copy data on fat

----------

## jeanfrancis

I keyworded the package, it works well on amd64... 

Backuping, got lots of bad blocks...

----------

## jeanfrancis

 *NeddySeagoon wrote:*   

> 
> 
> Do not attempt recovery in position. Read about dd_rhelp then use it to make a copy of the partiton to a file.
> 
> After you have a copy of all the data that can be read, you can try fsck on the damaged partition. If you are lucky, it will fix the problem. If not, it may make things worse. Hence the backup.

 

If you talked about fsck.vfat, I already tried it before... without success  :Sad: 

```

# cat backup.log | grep -i Bad

Bad block: 64

Bad block: 65

Bad block: 66

Bad block: 67

Bad block: 136

Bad block: 135

Bad block: 134

Bad block: 133

Bad block: 136

Bad block: 137

Bad block: 138

Bad block: 139

Bad block: 280

Bad block: 279

Bad block: 278

Bad block: 277

Bad block: 280

Bad block: 281

Bad block: 282

Bad block: 283

Bad block: 376

Bad block: 375

Bad block: 374

Bad block: 373

Bad block: 600

Bad block: 601

Bad block: 602

Bad block: 603

Bad block: 1080

Bad block: 1079

Bad block: 1078

Bad block: 1077

Bad block: 1392

Bad block: 1393

Bad block: 1394

Bad block: 1395

Bad block: 2792

Bad block: 2791

Bad block: 2790

Bad block: 2789

Bad block: 2792

Bad block: 2793

Bad block: 2794

Bad block: 2795

Bad block: 3128

Bad block: 3127

Bad block: 3126

Bad block: 3125

Bad block: 19128

Bad block: 19129

Bad block: 19130

Bad block: 19131

Bad block: 22200

Bad block: 22199

Bad block: 22198

Bad block: 22197

Bad block: 449880

Bad block: 449881

Bad block: 449882

Bad block: 449883

Bad block: 450104

Bad block: 450103

Bad block: 450102

Bad block: 450101

Bad block: 7119512

Bad block: 7119513

Bad block: 7119514

Bad block: 7119515

Bad block: 14209368

Bad block: 14209367

Bad block: 14209366

Bad block: 14209365

Bad block: 14245912

Bad block: 14245913

Bad block: 14245914

Bad block: 14245915

Bad block: 25525368

Bad block: 25525367

Bad block: 25525366

Bad block: 25525365

```

Was still running, ran out of space...

----------

## NeddySeagoon

jeanfrancis,

Yes, I was talking about fsck.vfat. You need not back up the whole drive, the partition is sufficient. However, if the drive is a single partition, thats not a lot of help.

If your drive is a single partiton, most of your bad blocks down to 22197 will be inside the first copy of the FAT. They are in the first 11Mb of the area you copied. 

If you copied a drive, with a VFAT partition as the first partition, then your Primary Volume Boot Record (VBR) is gone too, the second copy is still there. fsck.vfat will have tried to fix that. If it failed, than the area of the drive for the Primary VBR is probably unusable and recovery in place therefore not possible.

To proceed, you will need at least one copy of the drive/partiton, one to work on one as a backup. The process is make a copy, fix the VBR, then look at the FAT, if both copies are damaged, make a good copy from the two fragments you have. With the VBR and FAT both fixed, you can go after your data. Some data areas of the drive are lost. That does not mean that they actually contain data, so you may be lucky.

As you ran out of space, you don't know what dd_rhelp would have recovered for sure. It does a binary search to find and recover 'easy to read' areas of the drive, reading backwards and forwards up and down the drive. Backwards reading is slow as it defeats all the caching in system. When dd_rhelp has read all the easy to read areas it starts doing retries where it previously read errors. This can get further data - it only has to read once. You didn't get that far as you ran out of space.

Now it boils down to how valuable the data is to you and how much time you want to spend on recovering it.

It looks like you will need a replacement drive anyway but you can't tell for sure until you can do a write to every sector, which of course destroys all the data.

----------

## jeanfrancis

NeddySeagoon,

Thanks for all that help. I understand better now, And I'll try to move some data on friends' hard drives and make a copy of the disk on a 80 GB partition I have on another disk... I'll then be able to run dd_rhelp.

I have one big partition. I ran dd_rhelp with /dev/sdb1.

When you talk about restoring VBR and FAT, you talk about fsck doing it?

The data I have on the drive is not "that" important, but there is some personal stuff (pictures, videos, etc)... And I'll try to restore them, just to learn how to do it and then I'll be ready for a real "important data" loss the next time   :Twisted Evil: 

Thanks !

----------

## NeddySeagoon

jeanfrancis,

Knowing that your block error numbers are relative to the partition start, not the drive start helps a little.

Both your copies of the VBR are ok, as they are before block 64.

The first copy of the FAT is certainly badly damaged as is a part of the data area. The second copy of the FAT may be intact, it depends  on how big the FAT is for an 80Gb partition. 

Some approx calculations show that each copy of the FAT on a FAT32 drive will require 19074 disk blocks, with a 32kB allocation unit size.

This means that the damage before 

```
Bad block: 19128
```

is entirely within FAT copy 1 but the 19xxx and 22xxx block may well be in FAT copy 2. fsck.vfat cannot fix that. Thats a job for you and a hex editor by copying (hopefully) good blocks from FAT copy 1.

To do the arithmetic exactly, I need to see the VBR from the damaged partition. Try 

```
dd if=/dev/sdb1 of=neddyseagoon.vbr count=3 
```

then email me the neddyseagoon.vbr file.

----------

## jeanfrancis

Hi !

Thanks a lot, I'll do that !

But I won't go home before tomorrow evening, so I should do this at this time.

Thanks again  :Smile: 

----------

## jeanfrancis

OMG...

I was copying (copying first  :Smile: ) files from my 80GB partition to an external drive (I have a laptop here. The 80GB HD is an IDE connected via USB2)...

I wanted to move some files to this disk, then I could do the dd_rhelp with my 80GB disk in problem.

Then :

```

sd 3:0:0:0: SCSI error: return code = 0x08000002

sdb: Current: sense key: Medium Error

    Additional sense: Unrecovered read error

end_request: I/O error, dev sdb, sector 78381119

EXT3-fs error (device sdb1): read_block_bitmap: Cannot read block bitmap - block_group = 299, block_bitmap = 9797632

```

My both drives have such problems? I don't remember seeing them falling on the floor so... Is there any other option? This 40GB drive is an ext3 freshly formatted... Could a kernel/driver cause that? :S

----------

## NeddySeagoon

jeanfrancis,

A poor or damaged USB cable or using a USB hub may cause that.

Also external drives powered via the USB wire are very marginal, the USB port can barely supply enough power.

Its unlikely the drive is damaged.

----------

## jeanfrancis

Well, I'm out of clues..

I plugged the 40GB drive in, wrote a new partition table on /dev/sdb, and then /dev/sdb1 disappeared.... I have a bunch of IO errors on dmesg...

(Note that I'm using another USB cable and that the drive has a  power supply..)

----------

