Recovering Deleted Files from an NTFS Partition

02 Sep

Today I have had the pleasure of recovering about 20Gb of files which were deleted from an NTFS partition by our office Sysadmin Jr. Not entirely sure how he did it, but he managed to permanently delete the My Documents folder belonging to the primary user of the computer, who is one of the senior vets in our company.

As many sysadmins will already know, when a file is permanently removed from a computer all that happens is that the space currently occupied by the file is marked as free. Until that space is overwritten by another file, the data is still on the hard drive, and is recoverable by those in the know. The most important thing to remember in this situation is to power down the hard drive as soon as possible, pulling out the power cord if necessary. The longer the computer is left running, the more chance there is of another file using the space occupied by your data, rendering it unrecoverable to all but the most sophisticated (and expensive!) techniques. This is true even if the computer is just sitting idle, as the OS is constantly making small changes to files in the background.

Anyway, after instructions from me to power down & remove the hard drive (after checking to make sure the files weren’t in the recycle bin of course!), he handed me the drive and I proceeded to connect it to my Linux box (running Ubuntu, although a similar process will work on other distros) and begin the recovery process. Below is a summary of the steps I used, which resulted in the successful recovery of almost every missing file.

Before connecting the hard drive, I made sure that Linux was configured *not* to automount removable drives. I then connected the hard drive using an external SATA to USB connector.

Next, I took a clone of the hard drive (something I learned very early on to do whenever I’m working on someone elses system):

dd if=/dev/sdc1 of=~/hdd1.img bs=1024

This command uses dd to create an exact replica of the source partition (/dev/sdc1), putting the clone in the hdd1.img file in my home directory. By default, block size (bs) used by dd is 512. Apparently increasing this value can speed up dd. Of course, if you were to do this on another system, you would use a command such as fdisk -l to determine which source partition you need to use.

Once the backup of the partition was created, I installed a program called “ntfsundelete” using apt-get.

apt-get install ntfsundelete

Next, I ran ntfsundelete in scan mode to determine which files it could recover.

ntfsundelete -s -v /dev/sdc1

Note that ntfsundelete runs on an unmounted partition, and guarantees to make no writes to the source partition, something that is critical to maintaining the integrity of the drive and reduces the chances a deleted file is overwritten. The -s switch tells ntfsundelete to run in scan mode, while -v increases the verbosity of output.

Having determined that ntfsundelete would be able to recover data, the next command performs the actual recovery:

ntfsundelete -u -v -d ~/recoveredfiles -m ‘*’ /dev/sdc1

In this command -u tells ntfsundelete to run in undelete mode. The -m switch provides  a regex that tells the program which files to recover. In my case, I wanted it to recover all deleted files, hence the * wildcard. If you just wanted Word documents, for example, you could use -m ‘*.doc*’ instead. Once the command completes, all restored files can be found in the folder specified with the -o switch.

One downside to this application is that is the recovered files are all restored into the same folder, the folder struture that existed on the source volume is not recreated. This obviously creates an issue if the user has identically named files in different folders. I’m not sure if there’s a way around this, but it looks as though ntfsundelete just skips files with duplicate names. I suppose one option would be to identify the inode of the duplicate files using the -s scan mode, and then re-run in -u undelete mode using the -i switch to specify the inode and -o to save the restored file into a different directory.

Overall, a very useful tool and one more reason why I’ll keep pushing for more Linux in our enterprise. Now, where’s that drink Junior promised me?!

Leave a comment

Posted by on September 2, 2010 in Work


Add Comment

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: