Averting Disaster — Undeleting Files

Have you ever had the horrible sinking feeling that you just deleted a file you didn't want to delete? As fate would have it, it's usually something incredibly important to you, like your entire year's worth of personal financial data that you forgot to back up, or in my case, my last three months of On The Desktop columns. (Jason, don't worry. We've got them. ­Ed.)

Have you ever had the horrible sinking feeling that you just deleted a file you didn’t want to delete? As fate would have it, it’s usually something incredibly important to you, like your entire year’s worth of personal financial data that you forgot to back up, or in my case, my last three months of On The Desktop columns. (Jason, don’t worry. We’ve got them. ­Ed.)

For most of the PC world, this typically isn’t a major tragedy. Under Microsoft Windows or Mac OS, users are lucky enough to have such things as the “Recycle Bin” and the “Trash Can,” where the OS keeps track of all the files you’ve deleted, so you can happily retrieve them before permanently wiping them from your hard disk.

Unfortunately, under Linux it’s not so simple. When you delete a file on the Linux ext2 file system, be it in KDE, Gnome, or via the command line using the rm command, the file is gone — and there’s no friendly trash can from which to pull it. However, the file might not be gone permanently. The actual process of deletion doesn’t exactly erase the file from the disk, all it does is to unallocate that file’s inode, which is essentially an index pointer for that file.

Fun with inodes

Sound confusing? Maybe this will sound better. In Unix-style file systems like Linux’s ext2fs, there’s a finite number of inodes allocated for use in the file system — each inode has a unique number, which either points to a specific file or is free for use. When a file is created, an inode is used up and points to that new file. When a file is deleted, the inode pointing to that file is freed. Consequently, if you delete a file and then create a new file on the disk, there is the off-chance that the inode pointing to your old file has now been allocated to the new one — and then, you’re totally hosed.

So the first thing you want to do when you realize that you’ve just deleted the spreadsheet containing the database for your 3000 disk DVD collection, is unmount the file system that it is on. Why would you want to do that, you ask? With a multi-user, multitasking operating system like Linux, you never know when a process is going to want to write a file to disk, risking the possibility that the inode from your deleted file might get re-assigned. By unmounting the filesystem that the file was on, you eliminate the chance of this happening.

Unmounting the Filesystem

Let’s assume for a moment that your DVD collection database was stored in your /home/jason directory, which is an ext2 partition otherwise known as /dev/hda6. Your filesystem may be configured differently — on my Red Hat 6.2 system, I’ve configured my primary IDE disk into two partitions, a root partition (“/“), and a /home partition, with the physical device names of /dev/hda1 and /dev/hda6 respectively. To find out what filesystems are mounted on your computer, from a terminal prompt type df -k. You should get output similar to that found in Figure One .

To unmount your /home filesystem, you just issue the command unmount /dev/hda6 or unmount/home from a terminal prompt.

You might get an error message stating that the resource is in use and can’t be unmounted. If you deleted a file on the root file system (“/“) Linux will prevent you from unmounting it, and you’ll have to shut down the system and attempt to rescue the file using a boot floppy. You did make your kernel boot disk when you installed Linux, didn’t you? If not, there are a few web sites where you can download “mini” Linux distros that fit on a single floppy and that are effectively emergency boot disks. This allows you to boot a linux kernel, mount the root file system, and undelete your files.

My favorite one of these, which has saved my butt on many an occasion, is tomsrtbt (I’m not sure what this stands for, possibly Tom’s Root Boot?), which can be downloaded at http://www.toms.net/rb/home.html. Another cute mini-distro on a floppy is Pocket Linux, which you can get at http://pocket-linux.coven.vmh.net. Don’t wait until you’ve accidentally zapped one of your precious files –download one of these puppies now, and put it aside for when you actually need it.

Recovering Files

Okay. The sweat is dripping down your back, you’re biting your nails, you’ve unmounted your file system (or maybe you can’t) and now you’re ready to undelete some files. I strongly suggest that you take at least a cursory look at Aaron Crane’s Undelete mini-HOWTO. It can be found at http://www.praeclarus.demon.co.uk/tech/e2-undel/. It goes into unmounting file systems and file recovery in exhaustive detail, and explains a lot of stuff about inodes and the ext2 file system in general.

If the technical complexity of Aaron’s HOWTO begins to scare the hell out of you, you could always try to use the recover utility, which follows a lot of the procedures in Aaron’s HOWTO automatically and is the closest thing you are going to find to a magic undelete fairy. If your Linux distro doesn’t have recover installed, you should download, compile and install it right this very minute before a disaster actually happens.

The recover utility, written by Tom Pycke, can be obtained from http://www.linuxave.net/~recover/. You’ll want to download the recover-1.0a.tar. gz archive to a temporary directory. Then open up a terminal prompt and un-tar it by typing tarxvzf recover-10.a.tar.gz from within that directory. After that, run ./configure and make install to install it on your system.

To run the utility, simply type recover from any terminal prompt. You should get output that looks like Figure Two.

Typically, you should enter -1 or the actual current month, assuming your CMOS time and date are correct.

On which day of the week
did you delete the file?
(Mon, Tue, Wed, Thu, Fri,
Sat, Sun or -1=unknown)

Again, you should specify the current day of the week, or a -1 if you don’t know what day it is (hey, it’s possible, especially if you’re like our esteemed Publisher Adam Goodman who stays up day and night.)

What was the first possible
day of the month on
which you deleted the
file? (1 – 31)

At this point, you should just enter the number 1.

What was the last possible
day of the month on
which you deleted the
file? (1 – 31)

At this point, you should put in today’s date.

What was the soonest
possible hour(0-23) when
you deleted the file?

This is when you should look at your watch and narrow down the time window, otherwise you could end up recovering hundreds of inodes. A good bet is to go an hour back from your current time.

What was the latest
possible hour(0-23) when
you deleted the file?

Again, you will really want to narrow this down to the closest possible time to your current time, or to the hour when you think that you might have deleted the file.

You’ll then get a few more questions, which you should answer like the following:

What was the soonest possible
minute(0-59) when you
deleted the file? 0

What was the latest possible
minute(0-59) when you
deleted the file? 59

What was the minimum possible
file size in bytes?
(0-2147483640): 0

What was the maximum possible
file size in bytes?
(0-2147483640)

If you have an idea of how big the file was, you should enter it here. If you don’t, then just simply enter the largest possible number that it displays.

Finally, you are asked about the user who deleted the file:

What was the
user ID of
the deleted
file?(-1 if
you have
no idea)

If you don’t know who it is or what your user ID is, just enter -1.

Depending on the criteria, you should then get a list of inodes that can be recovered, as you can see in Figure Three.

Figure Three: Recovered Inodes

=> 470659 3874 MAY MON 22 22:27:43 2000

=> 470660 4615 MAY MON 22 22:27:43 2000

=> 470661 718 MAY MON 22 22:27:43 2000

=> 470662 6547 MAY MON 22 22:27:44 2000

=> 470663 3128 MAY MON 22 22:27:44 2000

=> 470665 1375 MAY MON 22 22:27:44 2000

=> 470664 4744 MAY MON 22 22:27:45 2000

7 inodes found. Where shall i dump
them? (directory): /root/recovered

At this point, you should specify the directory in which you want to put these files, typically on another partition. If your /home partition is dismounted, then you’ll want to dump them in a subdirectory of your root partition. I typed in /root/recovered simply because I know that partition on my disk has a lot of space on it, but if you have an NFS or a SAMBA share, you could easily put it on there too.

Cleaning Up The Mess

Hopefully, you shouldn’t have too many recovered files to dump — if you do, then you’ll want to filter things again until you come up with a manageable amount of files. Unfortunately, the names of the files and their extensions get erased when you delete them, so all you get back is the raw data. You’ll want to rename the files to something else (such as file.mp3,foo. png, bar.txt or whatever) and then try loading them in the program you think they go with. Have fun.

The moral of the story? Invest in a backup storage device like a tape unit or a Zip/JAZ/ORB drive or a CD recorder and remember to always back up your essential files! Then if you get into this mess, all you have to do is breathe a sigh of relief.

Jason Perlow is Senior Technology Editor for Linux Magazine and can be reached at perlow@linux-mag.com.