Reclaim Deleted Files and Repair Filesystems on Linux

4026

Linux is as solid an operating system as you’ll ever use — but that doesn’t mean that the hardware you’re running it on is equally solid. Hard drives are as prone to errors as are file systems. And no matter how stable an OS is, it can’t prevent you from accidentally deleting files and/or folders. But don’t despair: Linux is equipped with a number of tools that can help you repair filesystem errors and reclaim deleted files.

Which tools? To start, e2fsck, scalpel, and lsof will get you the farthest. Let’s take a look at how each of these can be used to help your file systems be free of errors and your files be freed from accidental deletion.

Checking Ext2/Ext3/Ext4 Filesystems with e2fsck

The e2fsck utility takes after the original UNIX fsck utility, but is used to check the Ext2/Ext3/Ext4 family of filesystems. It’s used to check, and repair, filesystems that have been shut down uncleanly or otherwise developed errors.

One problem most users face is that the e2fsck tool can only work on unmounted partitions. This can cause a problem if the file system you need to check is also the one you are working on. Many suggest switching your running system to run level 1 with the command (run as the administrative user):

init 1

However, I recommend you take this one step further and use a Live distribution like Knoppix or Puppy Linux or your distribution’s live CD if it has one. By booting into a Live distribution your disks will not be mounted and can safely be checked for errors. If, however you do not want to use the Live distribution you will need to make sure you do switch to run level 1 and then unmount the partition you want to check. Say, for instance, you want to check partition /dev/sdb1. To do this you would first switch to run level 1 (command shown above) and then run the command:

umount /dev/sdb1

With the target partition unmounted, you are ready to begin running the check. To do this enter the command:

e2fsck -y /dev/sdb1

The -y option assumes the answer is “yes” for all of the questions the command will present to you. Depending upon the size of your drive and the amount errors on your drive, this repair can take quite some time. Once the repair is complete, you can always run the command again to check if any errors were missed. When the drive comes up clean you can reboot into your normal system (If you used a live CD to run e2fsck, remember to remove the live disk upon reboot) or remount the unmounted partition.

Recover Deleted Files

Now let’s take a look at the process of recovering deleted files. The reason this is even possible is that a file is actually just a link to an inode on a disk. This inode contains all of the information for the file. When you delete a file you really only break the link to the inode so the file can really only not be found. The actual inode itself will remain on your disk… but only temporarily. As long as a process has that deleted file open that inode is not made available for writing. So, this method actually has a time limit, and a fairly short time period at that. The key to this recovery is the /proc directory. Every process on your system has a directory, within /proc, listed by its name. If you run the command ls /proc you will see a bunch of directories with numeric names as well as directories/files that have names that should look familiar. The most important directories are the numerically named directories. Those numbers are process IDs (PIDs) of running applications. You can always use the ps command to find the PID of the application you are looking for.

Once you have located the correct process in /proc you can then grab the data from the correct directory and save it again. File recovered. Let’s take a look at the whole process. I will demonstrate this with a fairly simplistic example which you can expand upon fairly easily.

Let’s create a file (say it’s a Bash script or configuration file) called test_file. Create that file with the command:

echo "this is my test file" > ~/test_file

Now you have a file called “test_file” that contains the single line “this is my test file”. Let’s delete that file and recover it. To do this we will view the contents of the file with the less command and then zombie that process so the data is being held. Here’s the steps:

Step 1: Let’s view the contents of that file with the command less ~/test_file.

Step 2: With that file open in your terminal window, hit the key combination Ctrl-z to zombie the process.

Step 3: Let’s make sure our test file still exists. If you issue the command ls -l ~/test_file you will see still your file there. So far so good.

Step 4: At the same command prompt issue the command rm ~/test_file to delete the file.

Step 5: Check to see if the file is there with the command ls ~/test_file. You should not see that file listed now. Because the command we used to view the file (less ~/test_file) was zombied, the data has been held. Let’s recover it.

Step 6: Issue the command lsof | grep test_file. This command will take some time to run, but will eventually spit out the needed information which will look similar to:

less 14675 zombie 4r REG 8,1 21 5127399 /home/zombie/test_file (deleted)

What we need is the PID of the file (Which is in the second column — in this example it is 14675) and the file descriptor (Which is in the fourth column — in this example it’s the number 4).

Step 7: Time for the actual recovery. With the information you have now you can recover that file with the command:

cp /proc/14675/fd/4 ~/recovered_file

Step 8: Let’s verify that the contents of the file are intact. Issue the command:

less ~/recovered_file

You should see that the contents are, in fact, the same. The contents of ~/recovered_file should be identical to that of the original ~/test_file. If so, you have successfully recovered a deleted file from your Linux system.

Recovery with Scalpel

There is actually an easier way to recover specific file types on a Linux system using the tool Scalpel. Here are the steps for installing and recovering using this simple tool.

Step 1: Installation. I will demonstrate on a Ubuntu 10.10 desktop. To install scalpel, open up a terminal window and issue the command:

sudo apt-get install scalpel

You will need to enter your sudo password and accept any dependencies (if necessary).

Step 2: Edit the config file. Issue the command:

sudo nano /etc/scalpel/scalpel.conf

Now take a look through the file. You will find lines that correspond to file types (such as .pdf, .doc, .png, etc). When you see a file type you want to attempt to recover just uncomment that line (remove the “#” character). When you have finished editing this file, save and close it.

Step 3: Recover your files. The first thing you must do is create a directory that will hold your recovered files. Let’s use the target folder ~/RECOVERED. With that folder in place, issue the command:

sudo scalpel /dev/sdX -o ~/RECOVERED

(Where X is the exact partition you want to scan).

Step 4: Wait. This process will take quite some time. Don’t even bother to watch it run or you’ll be watching for an hour or so (depending upon the size of your drive and how many file types you are attempting to recover.)

Step 5: Check the recovery folder. Once the command has completed, check the ~/RECOVERED folder (there should be sub-folders created on a per-file-type basis) to see if scalpel has recovered your files. If so, congratulations. If not, you can always try to run the command again (or on a different partition).

Final Thoughts

No one wants to have to deal with a corrupted file system or lost files. And although Linux has plenty of tools to help you when this occurs, nothing is perfect. Some times a file system or files can be too far gone to recover. But with a little care and intelligent use, you should be able to avoid having to use these tools all together.