NTFS partition is lost, but data (should be) there, how to recover?

Shortly: I've got troubles with a lost partition and Testdisk is not able to solve my problem. Everything makes me think that files are on the disk, but I don't know how to get them back. Also, I'm not an english native speaker, so I apologize for eventually doing some mistakes.

Details

I tried to resize a NTFS partition on my drive with gparted (linux was running), but the operation failed and I lost the filesystem.

This was the disk BEFORE:

125 GB - primary - NTFS (windows)
3 GB - primary - linux swap
21 GB - primary - ext4 (linux)

This is what I meant to do: shrink the NTFS partition FROM THE LEFT in order to make free space at the beginning of the disk. In gparted I edited the partitions like this:

60 (more or less) GB - unallocated
60 (more or less) GB - primary - NTFS (windows) (shrink)
swap and ext4 same as before (unchanged)

and clicked "Apply". During the process I was reading what was going on: it was transferring 30 GB of data from the first part of HD to the new smaller NTFS partition. This part was succesful (you know, shrinking process is made of several parts, and this files transfer was ok). Then I guess gparted tried to create the new MFT and update MBR but it failed. My biggest mistake of the day was that I didn't save the logs (does gparted automatically save logs?) but as far as I remember the error was something like "free clusters more than expected". Well, the result is the following:

67 GB - primary - NTFS (gparted says: "Failed to load runlist for $MFT/$DATA. highest_vcn = 0xc747, last_vcn - 1 = 0x1633b . Failed to load $MFT: Input/output error . NTFS is inconsistent")
57 GB - unallocated
swap and linux are unchanged

I run Testdisk from a bootable USB, I did quick scan but it didn't find anything new. With deep scan it found an additional NTFS partition:

NTFS 0 32 48 16305 55 6 261941233

but when I type "enter" or "p" to view files it says "partition is corrupt".

Some notes:

1) it's strange that my instructions were to create free space BEFORE NTFS, but what gparted sees now is unallocated space AFTER NTFS. And NTFS is inconsistent. Maybe gparted created the new MFT in the first partition and failed to copy to the second?

2) from what I read during the operation, the files should be all in the unallocated space.. how can I find them? I would try to recover them in an ordered way, since if I use PhotoRec I would loose any directory structure.

What should I do? please help or my girlfriend will kill me! (it's her computer.. :O )

Solution 1:

This is how I finally managed to recover some files from the disk. I know that part of the answer will be off-topic (since I used many windows programs) but for the sake of completeness I wish to share my experience for future users.

The most important lesson I learnt is BACKUP YOUR DATA BEFORE RESIZING A PARTITION.

Since TestDisk was not helping me, even with deep scan, I decided to use PhotoRec. Luckily I had a disk backup that was 3-4 months old, so I aimed to recover all files from the disk and filter only useful ones, the ones that were created after my last backup.

1st scan with PhotoRec was for the whole disk. It recovered 5700 files (2,12 GB) but then started looping and sector count was going backward.

In the 2nd scan I set to scan only the NTFS half. It recovered 56800 files (40 GB).

I needed to scan the 2nd half of the disk, so I started a whole disk scan again, I stopped it and I edited the session log file. I manually entered a number that was a few million sectors before the end of the part it was already done. I started again PhotoRec, I told it to resume session and.. magically! It managed to scan only the 2nd half of the disk. 128400 files were found (43,5 GB).

I copied the 3 scans in a folder named “PR_scans” using FreeFileSync.

I installed Cygwin. I created another empty folder named “Processing” that I used to catch some useful files and to compare them against the backup.

In Cygwin I used commands like:

find PR_scans/ -iname '*.jpg' -size +250k -exec mv -vi {} Processing/ \;

to find useful files. I found 250k was a good cut-off size to separate personal photos from internet cache files. For other kinds of files I set no minimum size:

find PR_scans/ -iname '*.docx' -exec mv -vi {} Processing/ \;

I repeated this operation for all meaningful file extensions (doc, xls, xlsx, pdf, png, mov, avi, etc.)

I finally used Duplicate Cleaner Free to remove all files from Processing folder that were already present in my old Backup.

The creator of RecuperaBit contacted me on this site so I decided to test this tool that seems quite magic.

RecuperaBit found a total of 13772 files (22,2 GB), against 13500, 30,8 GB that was the size of my 3 months old backup. This seems pretty good. Of these files:

• 8700 files were exact duplicates of files in my old backup
• 4000+ files had same name but different content, because they have been modified in the meanwhile or because RecuperaBit recovered damaged content.
• most interestingly: 395 were duplicates of PhotoRec files not in my backup, this means that PhotoRec recovered the content, but RecuperaBit recovered filename and path!!

Solution 2:

Assuming the move actually went as expected the data should be there.

While I do not know how to rebuild the partition table I have successfully recovered data off a drive with a destroyed partition table using:

http://www.r-studio.com/

While I can't promise success the attempt is free--the demo version is crippled only in it's lack of ability to recover non-trivial files. You see exactly what it thinks is there and you can recover small stuff to have a look to see that it is being sane.

Note that you'll need another drive to use this approach.

While you're trying that, 20 lashes for playing with a partition editor without a full backup!

(I have no connection to the company other than being very happy with the results when every other tool I tried couldn't do squat because a RAID situation had put the partition table in a non-standard location.)