# Failed disk, incomplete image, mount anyway?

## The_Great_Sephiroth

I have a friend who had her 40GB disk (old XP system) die. I have been running ddrescue on a Gentoo laptop with a USB-IDE cable for two days now. It has stalled at 99.87% for a day. That is the last 51MB of data. Is it possible to mount the incomplete partition in the image? The partition started at sector 63 and the disk had 512b sectors. She wants her files if possible.

----------

## NeddySeagoon

The_Great_Sephiroth,

Maybe.  It depends where that 51MB is.

Post the ddrescue log file.  If you are really really lucky, it will be in unallocated space.  

If you are very unlucky, it will be the top level directory or metadata.

You don't say what the filesystem is.

Its its a non journaled filesystem attempting a ro mount is harmless.

On a journaled filesystem, even a ro mount can cause a journal replay and you don't want that until you have given up and the remaining data,

----------

## The_Great_Sephiroth

Since it was an XP system, the FS is NTFS, of course. I am assuming a default of 4k cluster size. I have no clue where this 51MB is. I invoked the rescue as shown below.

```

ddrescue -b 512 /dev/sdb /home/username/backup.img /home/username/backup.map

```

Do you mean the map file? That is what ddrescue calls it.

----------

## NeddySeagoon

The_Great_Sephiroth,

NTFS is journaled. Yes, the map file then.

It used to be a text file - here's one I prepared earlier.

```
# Rescue Logfile. Created by GNU ddrescue version 1.15

# Command line: ddrescue -M -d -b 4096 -r 16 -f /dev/sde /dev/sda /root/copy_log.txt

# current_pos  current_status

0x1844FF15000     +

#      pos        size  status

0x00000000  0x1800933D000  +

0x1800933D000  0x00001000  -

0x1800933E000  0x8FBFA000  +

0x18098F38000  0x00001000  -

0x18098F39000  0x3B6FD9000  +

0x1844FF12000  0x00004000  -

0x1844FF16000  0x4D71200000  +
```

Hex numbers are bytes.

+ means the data was recovered

- means the data is still missing.

That's two single 4k blocks and an area of 4 4k blocks.  That drive had 4k physical sectors.

If you cat the file while ddrescue is still working there are other symbols too. 

```
ddrescue -b 512
```

isn't very aggressive.

```
ddrescue -M -d -b 512 -r 16
```

may get some more.  I'll leave it for you to read the man page before you try that.

You give it the same map file and ddrescue only tries areas that are not yet recovered.

----------

## The_Great_Sephiroth

I know -d is direct off the top of my head, but I will research the rest. I have always had luck using "-b <physical sector size>", but maybe I have never run into a drive this far gone.

This is why I, like your signature states, do backups. I have an old Pentium D (64bit, dual-core) system running Rockstor on a RAID10 array. BTRFS secures my data, and I love it. This friend never did ANY kind of backup.

----------

## The_Great_Sephiroth

The map file has locations all over the disk. After all of this time it recovered 2MB more. I am going to copy the image and attempt to mount it. If it works I can get the data off and be good. If it doesn't, I have to keep trying until I need my other laptop back.

*UPDATE*

I just tried this. It mounts and I can browse every directory on the system, EXCEPT her music, videos, and pictures. Attempting to access those three directories results in an IO error. She may be out of luck.

----------

## cboldt

You might try photorec, from the "testdisk" package.

----------

## NeddySeagoon

The_Great_Sephiroth,

That means that there is missing metadata still.

Run that 

```
ddrescue -M -d -b 512 -r 16 ...
```

again, with the same log file but try the drive on all six faces and some angles in between.

You only need coax one more read ...

If you move the drive while its spun up, do it slowly. Take care that the coriolis force does not damage the spin motor bearings.

Once you get to moving the drive deliberately, larger values of -r may help.  That's retries.

----------

## The_Great_Sephiroth

It spins fine and all. The issue is the physical magnetic disk is going bad. ECC errors and reallocated sectors in SMART data. I guess it is losing magnetism. I have kept the disk perfectly still during this recovery process.

----------

## NeddySeagoon

The_Great_Sephiroth,

Try all the faces/edges.  The idea being that gravity changes the head/track alignment by a small amount, which may or may not help reads.

You should get a reallocated sector every time a read succeeds.

If the platter has shed magnetic material into the enclosure, it normally gets onto the head and into the head/platter airgap.

This is a very bad thing. The disk becomes unreadable almost everywhere very quickly.

The very last ditch step is the freezer method.  I've not needed to resort to that.

-- edit --

Something to try on the image.  ntfs fsck. The name is probably wrong.  

It may well make things worse - hence do it on the image.

However, NTFS does keep two copies of some metadata, so it may help.

----------

## The_Great_Sephiroth

It's still going. Still has 49MB to go. Has not stopped since my last post. I believe the disk and data is gone. Unless she wants to pay a LOT of money to a data recovery company, that is. Thanks for all of your help, Neddy. I am calling it a day on this one.

----------

