Recovering data from an NTFS laptop harddrive with MFT failures
A client brought me a Dell Inspiron 5150 and reported it wouldn’t boot. Other techs had looked at it and reported a hard-drive failure. I learned the drive was mechanically operable and that the NTFS file system had suffered a double MFT failure. The MFT is the Master File Table, which you can read about in the Internals section of the Wikipedia NTFS article linked above. Without it and with it’s backup lost also, the OS and most recovery methods had no means of locating files on the physical media. Detailed below is the process I used to analyze the problem and then to recover much of the data from that filesystem.
First, I used an IDE to USB adapter to connect the harddrive, removed from the laptop, to my Linux workstation. I use Ubuntu 12.04 right now, but that’s not important. I had to work as root. Here’s how it went, blow by blow from then: Then, I used dd_rescue to duplicate the entire drive into a “raw .img” file on my hard drive so I could work from a copy instead of the original. The command line was simply:
dd_rescue -v -l /media/laptop-sdb.log /dev/sdb /media/laptop-hdd.img
Then I tried “loop mounting” the NTFS partition in that image to a mount point on my filesystem. First, I looked at the partition table to find out where in the image the first partition starts:
root@mjdlnx2:/media# fdisk -l laptop-hdd.img Disk laptop-hdd.img: 60.0 GB, 60011642880 bytes 255 heads, 63 sectors/track, 7296 cylinders, total 117210240 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0xf52bcf0e Device Boot Start End Blocks Id System laptop-hdd.img1 * 63 117194174 58597056 7 HPFS/NTFS/exFAT
Now I know there’s a single parition, likely holding an NTFS. It starts at cylinder 63, which is normal. Now I need to know how many bytes that is so I can tell the loop mount command (losetup on Linux) where in the hdd img file to find the start of the partition. There’s 512 bytes per cylinder, according to the fdisk output above.
root@mjdlnx2:/media# echo '63 * 512' | bc 32256
So, that’s 32,256 bytes. I’ll use that as an argument to losetup next, and then mount the loop device losetup creates for us. You’ll see the error messages from the mount command that tell me the MFT is bad:
root@mjdlnx2:/media# losetup -o32256 /dev/loop0 /media/laptop-hdd.img root@mjdlnx2:/media# mount /dev/loop0 /media/t/ ntfs_mst_post_read_fixup_warn: magic: 0x43425355 size: 1024 usa_ofs: 32296 usa_count: 35161: Invalid argument Record 0 has no FILE magic (0x43425355) Failed to load $MFT: Input/output error Failed to mount '/dev/loop0': Input/output error NTFS is either inconsistent, or there is a hardware fault, or it's a SoftRAID/FakeRAID hardware. In the first case run chkdsk /f on Windows then reboot into Windows twice. The usage of the /f parameter is very important! If the device is a SoftRAID/FakeRAID then first activate it and mount a different device under the /dev/mapper/ directory, (e.g. /dev/mapper/nvidia_eahaabcc1). Please see the 'dmraid' documentation for more details. root@mjdlnx2:/media#
OK, so I can see something is wrong. I’d already tried chkdsk earlier and had similar reports of “can’t do it” from that program. So I used a program called testdisk on my linux workstation next. It’s a tool you run in a terminal window on Linux. It’s a menu driven program, so I’m not going to show everything I did with it. Here are the steps, though:
- at the command-line, I start testdisk like this:
testdisk /media/laptop-hdd.img
- select media laptop-hdd.img and “proceed”
- choose [Intel] partition table type
- I did an [Analyse] and in there, [Quick Search] and then “P” to list files and it told me the file system is damaged.
- Then I quit back to the main menu and went to [Advanced], [Boot]. It says the boot sector and it’s backup are OK and identical.
- I tried to use [Repair MFT] since it’s the MFT that mount complained about.
- Got this message: “MFT and MFT mirror are bad. Failed to repair them.”
- That’s the end of this game.
The Master File Table (MFT) and it’s backup were both corrupt, making most normal recovery techniques impossible. Most of those methods rely on copying the backup MFT over the primary. Once I’d discovered that, I purchased a license for Zero Assumption Recovery’s data recover tool.
I have my Windows 7 workstation in a VirtualBox VM. So, I made a copy of the laptop-hdd.img file with VBoxManage, converting it on the fly into a .vdi that my VM could attach as a D: drive. Here’s that command:
cd ~/VBox/vdi VBoxManage convertfromraw /media/laptop-hdd.img laptop-hdd.vdi
Then I started up the VirtualBox UI, edited my VM storage settings to add the new laptop-hdd.vdi as a disk on my virtual SATA controller and then started my VM. I installed the ZAR program I’d bought and used it’s dead simple interface to do everything else. It scanned the drive and assembled what it found into a tree structure with that was largely intact. It stored the many unidentifiable files and directories in two new root level directories called “Lost Directories” and “Lost Files.”
Once the recovery was finished, I simply marked what I wanted copied in the ZAR recovery interface, “aimed” it at a folder on my VM’s desktop and clicked “go” or whatever it said. When that was done, I just copied that folder to a 65GB USB stick for my client and away she went, mostly happy.