testdisk is showing wrong size of drive

Question

I'm trying to recover the data of a damaged hard drive using testdisk. I did all good, did the quick search, the deeper seach, and then, after confirming that my files had been found by testdisk, I wrote the partition table. and restarted the computer. So, now I think I got an even bigger problem. The hard disk is now sowing in testdisk as a 2199GB drive, and if I plug it directly into the SATA port, as recommended in the testdisk FAQ, even my BIOS can't recognize it properly, and I can't run testdisk again since it doesn't recognize the drive with it's normal size (that's 500GB).

Trying to mount the drive for read only to an attempt to recover data isn't working either, I get the message that the "NTFS is inconsistent".

I tried to see the drive in the Windows Disk Manager, but it takes a really long time to show up, and still showing as raw, with no info about its size.

the output of testdisk in recognizing the drive. You can see my personal hard drive(sda) and the drive I want to recover(sdb) both should list as 500GiB.

One thing to note is that the disk space ocupied in the list by sda(my hard drive) is the disk space occupied by the hard drive I want to recover. Actually the amount of disk space ocuppied in my HD is 110GB.

I can confirm that the drive isn't dead because the LEDs light up and I can feel the disk running.

if I use smartmontools or gsmartcontrol to see the hard drive status I get this as result:

the details screen for the drive

It's very important for me to recover that data because it evolves college and master's degree material, and my last backup is from 1 month ago(I can't do it everyday due the space avaliable in my backup External USB Drive).

I hope someone can help, and I know that a lot of people have this problem too.

Facts that can be of useful knowledge:

• R-Studio demo was useless in my test, if I try to open it with the drive pluged the program just doesn't work/doesn't respond.

• WD Lifeguard Diagnostic isn't proofing useful either, since it doesn't show the drive on it's table.

• The drive doesn't look psychically damaged.

EDIT 1:

As requested, the [ Geometry ] screen:

Should I try to tweak the number so they show the true disk capacity or there's a recovery option?

EDIT 2: The drive is a WD Blue, model WD500LPVX

EDIT 3: The command parted -l /dev/sdb output goes as below:

the sudo grep -abiro "NTFS " /dev/sdb command output gave me, after some time of running:

grep: /dev/sdb: Input/output error

Correcting the print, looks like the sdb unmounted before I did the parted command, the image above is the real output.

One thing to notice, the grep command after the first output taking around 20 seconds, does instantly give the same output if I run the command again without unplugging the drive.

EDIT 4:

ddrescue has been running for some hours by now, but I'm finding some points weird in the behavior of the outputs, as follow:

First, a sample of some lines of the status.log file:

# Rescue Logfile. Created by GNU ddrescue version 1.19
# Command line: ddrescue /dev/sdc /media/sidious/Supply/dotk/bkpHD/copy.img /media/sidious/Supply/dotk/bkpHD/status.log
# Start time:   2016-07-29 01:05:36
# Current time: 2016-07-29 01:30:51
# Copying non-tried blocks... Pass 1 (forwards)
# current_pos  current_status
0x8482360000     ?
#      pos        size  status
0x00000000  0x00010000  *
0x00010000  0x00010000  ?
0x00020000  0x00010000  *
0x00030000  0x00020000  ?
0x00050000  0x00010000  *
0x00060000  0x00040000  ?

Should it be like this?

Second, the command output can be seen here:

I'm not sure if the values presented in the rescued, ipos, and opos are wrong or not, so I ask someone to tell me if should be like this. the drive has a real capacity of 500GB, and some of the numbers shown are bigger than that.

Also, the size of the copy.img file is 0 bytes. Does this means that there's no data being copied or that there's no sucessful data to recover?

EDIT 5:

After a long process and wait, with a lot of replugging the drive to keep the process going, looks like ddrescue finished, but the .img file has 0 bytes. Did I do anything wrong? I just followed the instructions given.

EDIT 6

I'm marking this question as solved, since the process given to solve the error would mostly work if the drive wasn't "dead". Thanks to everyone who gave it's thoughts and especially to Andrea Lazzarotto.

Answer 1

The drive doesn't look psychically damaged.

Luckily, hard drives do not have feelings. ;) However, I am sorry to inform you that your drive looks physically damaged or at least is reaching failure:

does instantly give the same output if I run the command again without unplugging the drive

This basically means "not good".

The things you must absolutely do in this case are:

• stopping any write on the drive (you already stopped attempting to re-write the partition table with testdisk, which is good)
• making a bitstream copy (aka image file) of the failing drive

Clone the drive

First of all, install the ddrescue tool through the gddrescue package (the g is not a typo), which is used to make accurate copies of failing drives, cloning as much information as possible. I will basically quote this answer of mine on a related question:

sudo ddrescue /dev/sdb /media/user/External/copy.img /media/user/External/status.log

The status.log file is not mandatory, but it is needed if you want to pause the process and resume later on.

As you can see, you will need another drive that is big enough to hold a copy of the entire 500GB drive (basically, a hard disk at least 1TB large). In my example it is mounted on /media/user/External. Adapt the example to your situation.

The ddrescue tool saves its progress in the /media/user/External/status.log file. This is very useful because the drive might "disappear" due to I/O errors (like it did while grepping). The program will stop. You will re-connect the drive and run the same command again: it will continue from where it was stopped.

Moreover, ddrescue reads "good" and "big" blocks first, then it comes back to more damaged areas later trying to reduce the amount of data read in a single operation until all the good bits have been isolated.

Even though the drive shows as being a 2TB drive, it is actually a 500GB drive. Therefore, the process of copying the drive will stop at 500GB.

Run TestDisk on the copy

Now you can use TestDisk like you did before, but on the copy:

sudo testdisk /media/user/External/copy.img

When you arrive at the point of seeing the contents of the partition (with the P key), do not go on for writing the partition table. Instead, use the C key to start extracting data you need (hopefully it could be not damaged).

For this operation, you will need free space on any drive (either on the one you used to store the bitstream copy, or a USB key or whatever) in order to extract the files.

If TestDisk fails

If TestDisk cannot access the NTFS drive because it is not damaged, you can use RecuperaBit to reconstruct the NTFS structure as explained in the aforementioned answer.

Disclaimer: I am the developer of RecuperaBit.