can not get ntfsfindbad to work

[Rafael Sanchez]

I have a 2Tb failing HDD which I partially recovered using DDRESCUE.
Final result was 1653 Gb Recovered, 346 Gb unreadable, 1398 bad areas.
Tried to run NTFSFINDBAD to find out which files had been totally recovered and which ones only partially recovered.

On the recovered drive, I run Fdisk with foll. output

fdisk -lu /dev/sdb

Disk /dev/sdb: 2000.4 GB, 2000398934016 bytes
255 heads, 63 sectors/track, 243201 cylinders, total 3907029168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x921383e0

Device Boot Start End Blocks Id System
/dev/sdb1 2048 3907026943 1953512448 7 HPFS/NTFS/exFAT

Then tried to run (again on the recovered drive, not on the failing drive) ntfsfindbad, with following result:

ddru_ntfsfindbad /dev/sdb1 ~/Desktop/rescued_logfile -i 1048576
ddru_ntfsfindbad 1.4 20141014
Reading the logfile into memory...
Reading boot sector...
ERROR! This program only allows for 8 sectors per MFT record, and this partition reports 7474
ERROR! Unable to correctly process the boot sector

Assume that was happened is that the MFT was corrupted in the failing drive and copied the corrupt MFT into the rescue drive, is this correct? however, the rescued drive seems fine with files accesible.

Any indication how should I proceed? Should I run chkdsk /f to try repair the MFT? (sorry I am a windows user)

I would appreciate any help. Thanks beforehand

[maximus57]

Your command:
ddru_ntfsfindbad /dev/sdb1 ~/Desktop/rescued_logfile -i 1048576
should be using /dev/sdb, NOT /dev/sdb1.

The whole reason to find the partition offset is to locate it based on the start of the whole drive, as that is how you did the recovery. You are supplying the offset but also using the partition as the base location, so it is looking in the wrong spot for the partition boot sector. If it can't process the partition boot sector, it can't find the MFT. I will have to look at my code, as I thought it should check for the NTFS signature first and report that as an error which may make more sense to someone.

And good luck with that recovery. 346 GB is a large error size.

[Rafael Sanchez]

Thank you very much for your reply. Using the command as instructed by you, ntfsfindbad run perfect.
Unfortunately, disk is so damaged that recovery prospects, even with luck, are scarce.
One last question, is there any easy way to convert the inode (as reported by ntfsfindbad log) into sector numbers? if affirmative I could concentrate on trying to recover files with few sectors damaged and forget about the rest.

[maximus57]

Actually there is a way. Look at the documentation for the --debug option for ddru_ntfsfindbad. It will produce an output that includes the offset and size for every piece of an inode. I have included a small sample of the output below. Note that inodes can have more than one part (indicated a fragmented file). You can use the fulloffset as the --input-offset and the size as the --size for custom ddrescue commands to focus on specific files. Make sure to keep using the same logfile you have been for all your commands.

inode=819  part=0  offset=0xA1D70000  fulloffset=0xA1E70000  size=0xBA8000  type=0x80  errors=5  errorsize=2560
inode=819  part=1  offset=0xA8304000  fulloffset=0xA8404000  size=0xF24000  type=0x80  errors=12  errorsize=6144
inode=819  part=2  offset=0xA95C5000  fulloffset=0xA96C5000  size=0xC63000  type=0x80  errors=13  errorsize=6656
inode=819  part=3  offset=0xD8F0F000  fulloffset=0xD900F000  size=0x523800  type=0x80  errors=3  errorsize=1536
inode=822  part=2  offset=0x10F766000  fulloffset=0x10F866000  size=0xEE2000  type=0x80  errors=10  errorsize=5120
inode=822  part=3  offset=0x11293C000  fulloffset=0x112A3C000  size=0xD0C000  type=0x80  errors=9  errorsize=4608
inode=822  part=4  offset=0x11A9DA000  fulloffset=0x11AADA000  size=0x61BDD8  type=0x80  errors=5  errorsize=2560
inode=829  part=0  offset=0x12B031000  fulloffset=0x12B131000  size=0x4F0200  type=0x80  errors=3  errorsize=1536
inode=833  part=0  offset=0x9F2E8000  fulloffset=0x9F3E8000  size=0xC97000  type=0x80  errors=6  errorsize=3072
inode=833  part=1  offset=0xD63D9000  fulloffset=0xD64D9000  size=0x3743B9  type=0x80  errors=4  errorsize=2048
inode=838  part=0  offset=0x103663000  fulloffset=0x103763000  size=0x65000  type=0x80  errors=1  errorsize=512
inode=838  part=1  offset=0x110C27000  fulloffset=0x110D27000  size=0x422000  type=0x80  errors=5  errorsize=2560
inode=840  part=0  offset=0x111C28000  fulloffset=0x111D28000  size=0x3068E8  type=0x80  errors=4  errorsize=2048
inode=844  part=0  offset=0x11FA7B000  fulloffset=0x11FB7B000  size=0x258000  type=0x80  errors=1  errorsize=512

Using this sample, say we wanted to focus on recovering inode 819 which has 4 fragments that have errors. You would use commands similar to the following, making sure to include the "0x" in the number (so it knows it is a hex number).

ddrescue -f /dev/sda /dev/sdb rescued_logfile -i 0xA1E70000 -s 0xBA8000
ddrescue -f /dev/sda /dev/sdb rescued_logfile -i 0xA8404000 -s 0xF24000
ddrescue -f /dev/sda /dev/sdb rescued_logfile -i 0xA96C5000 -s 0xC63000
ddrescue -f /dev/sda /dev/sdb rescued_logfile -i 0xD900F000 -s 0x523800

[maximus57]

FYI

Picture files can sometimes survive a few small errors with little to no noticeable affect, although that is not always the case.

Video files can often handle a few small errors and only have small glitches.

Microsoft Office documents don't handle errors very well at all and will probably not even open and will likely not be able to be repaired.

All other types of documents/files are at the mercy of whatever program opens them.

[Rafael Sanchez]

Very concise and helpful reply.
Before asking I have been searching in Google for quite some time but I didn't find any information I could make practical use of.
Once again, thanks for your time and for sharing your knowledge!!!!

[KDEboroda]

Thanks for your toolkit!
Having read the topic, I have an idea:
Can you please extend the output format of debug file or somehow automate the process of creating a domain_mapfile to run ddrescue, to get an example of such a type:

0xA1E70000 0xBA8000 + # inode=819  part=0  filename="***!@#$%***"
0xA8404000 0xF24000 + # inode=819  part=1  filename="***!@#$%***"
0xA96C5000 0xC63000 + # inode=819  part=2  filename="***!@#$%***"
0xD900F000 0x523800 + # inode=819  part=3  filename="***!@#$%***"

I have a similar situation. HDD_size=3Tb, still pending_to_rescue=212Gb. Some files are damaged only a little, some are not needed (present in other drives), so I would like to analyse the situation to maximize the recovery before the drive goes to the seller while it still has warranty.
As for now, I am unable to see any list at all. 7680 inodes; 181000 lines of ddrescue_mapfile, 512M of RAM, 200 M of free space on system drive, Lubuntu 16.04 LTS.