Data Recovery with Scrounge NTFS

A friend asked me to try to recover data from an external 160 GB hard disk. It refused to show its contents on Windows XP, where it used to be used. In an earlier similar situation I had successfully used scrounge-ntfs. Scrounge NTFS is available as an out-of-the-box package for Debian Linux, which I run on my desktop computer at home. So I gave it a try in this case too. I connected the disk to a USB port of my computer, where it got the device ID /dev/sdb.

To use scrounge-ntfs, one needs some pieces of information (items copied from the author's website):

• Start Sector: This is where the partition starts on your hard disk.
• End Sector: Where your partition ends on the entire hard disk.
• Cluster Size: This is the size of one 'block' of data on a partition
• MFT Offset: The position of the NTFS Master File Table.

I didn't know this data, but I let scrounge-ntfs guess it: scrounge-ntfs -l /dev/sdb
I got
Start Sector End Sector Cluster Size MFT Offset
63 312579729 8 6291456
So I changed into the directory where I wanted the recovered data to end up and entered
scrounge-ntfs -m 6291456 -c 8 /dev/sdb 63 312579729
Unfortunately, scrounge-ntfs just complained about an invalid mft-record and stopped.
There is the option of running scrounge-ntfs without telling it where the MFT is. But if run so, it places all recovered files into one single directory. Manually sorting more than 20,000 files is not particularly funny, so I wanted to aim for a better result.

According to Stef Walter, the author of scroungs-ntfs, sector 6291456 is a customary place for the start of the MFT. Given the error message, I assumed that the usual place happened to be on a damaged sector. After a little thinking, I dared to use a trick: let it look for the MFT one sector after the original one, i.e. scrounge-ntfs -m 6291457 -c 8 /dev/sdb 63 312579729
I didn't really expect this to work, but it did. Although every message about a recovered file is preceded by scrounge-ntfs: invalid mft record, all files were recovered and by far most of them ended up in a meaningful subdirectory. So my friend is happy of having his data back again.