How to recover a removed file under Linux?
By accident, I used rm on a file I didn’t want to delete. Is there a way that I can get it back under Linux?
@Nav, rm is a «dangerous» UNIX/Linux command (read $ man rm ). Use it with extreme caution. With that said, it is a quick way to delete files you are sure of. Modern Linux and Unix Desktop Environments do provide with a solution of «Trash Can», so the user easily can recover accidentally deleted files.
Don’t use «rm» if you wish to restore the files in future .Use «rm-trash» utility instead : github.com/nateshmbhat/rm-trash
15 Answers 15
The following are generic steps to recover text files.
- First use wall command to tell user that system is going down in a single user mode:
# wall System is going down to . please save your work. grep -b 'search-text' /dev/partition > file.txt grep -a -B[size before] -A[size after] 'text' /dev/[your_partition] > file.txt -i : Ignore case distinctions in both the PATTERN and the input files i.e. match both uppercase and lowercase character. -a : Process a binary file as if it were text -B Print number lines/size of leading context before matching lines. -A: Print number lines/size of trailing context after matching lines. # grep -i -a -B10 -A100 'nixCraft' /dev/sda1 > file.txt This method works wonders for text files, thanks! What I like about it is that it doesn’t rely on the filesystem’s journal (like extundelete), but it actually scans the raw bytes of the entire drive instead. If this command doesn’t find your file, nothing will.
@Quinma, this method can work remotely with only slight modifications. Instead of running init 1 , manually kill every system daemons except sshd . I also think at this point you should be remounting all filesystems RO and saving to tmpfs (assuming your temp files will fit in ram) to avoid overwriting the files with the temp data. You will of course have to copy it elsewhere later, either to a remote server or back to local filesystems after remounting them RW.
@Qback, I really don’t know. As stated, I just followed the step-by-step. But the init 1 is meant for administrative tasks, and maybe kill process not related to that runlevel scenario. That may help preventing harddisk from being used, overwriting the file you’re trying to recover.
- If it’s very-very important, take the disk from the computer and hire a company to do it for you.
- If it is only very important, mount the disk read-only, copy the whole partition to a file using dd and try to find the file within it (using grep , or an editor).
Edit: sometimes ddrescue works better than dd .
«try to find the file within it» I’m confused, how would one reasonably open a 15+ GB file and search or pipe this beast into grep? And what would you do when you found the text? How on earth is this recovery?
The first thing to do is to try some common tools before burning a lot of cash for an uncertain result. BTW, grep won’t really help, photorec or ext3grep will.
If your filesystem is ext3, use ext3grep.
Testdisk has an undelete option that should work with Linux.
There is a walkthrough for Linux. Note that it works for ext2, ext3, and ext4.
extundelete is also handy if the partition is ext3/4. However, the first thing to do is perhaps to unmount the partition.
I did this a couple of years ago. My approach was to directly, no time to lose, unmount partition and then
dd if=/dev/hda1 of=backup_image.ext3 to have a backup file of the exact state of the partition. Then you can mount the partition again and continue with business as usual as you search for the the deleted file in your created image. The image will probably be VERY large since you need all the «empty» space, so it might be a practical problem to store it.
Then it was just to perform boring searches after text snippets I expected to be somewhere in the soup of partition content. E.g. to find .tex-files, I ran
grep --binary-files=text -1000 "subsection" < backup_image.ext3 >latexfiles which printed a large context around the phrase «subsection» and saved the output to a file to be manually searched through. I printed such a large context since it took such a long time to search the image that I’d rather not do it more times than I had to.
Also the command strings was helpful in removing binary garbage from the output, but if I recall correctly it also stripped all newlines, which could be a problem.
To find binary files in the same way, one might have success in finding a characteristic header or something of a certain file, but I imagine it to be a rather big adventure.
Brief technical notes: there are technical difficulties with disk recovery and Ext3/4. It is a long thing to explain, but briefly (and inadequately): Ext3/4 removes the «markers» that tell the OS where files are located on disk when you delete them. The files aren’t scrubbed, but no one knows where on the disk they start and end anymore, and sometimes they even are fragmented at several places. Some other file systems just set the files’ statuses to «deleted», but keep the location data. Then undelete is not harder than to look at file pointers with this flag (they should still be available if not too much activity has occured), and then hope their content has not been overwritten.
What is best? Rhetorical, in my view. Frequent backup is the answer to all these problems. Important data without an automated backup system is an accident waiting to happen, IMHO.
Obligatory personal anecdote: I was going to remove foo\ foo* from ~ . I wrote
, which sadly, since foo apparently was a symlink and the only file matching this, the shell made into
I pressed Enter and sat there looking at the command, which should have taken a second at most. After a bit longer time rm asked me if I wanted «to remove the write-protected file ‘something'».Quite quickly I felt the chills and softly and very controlled I pressed Ctrl+c . ~Half of my ~ was deleted, but I managed to get everything of value back through above described grepping and some more or less current backups. I had some personally very valuable (read: time consuming) and very recent measurement data on disk that was lost, but I had made quadruple backups. One disappared here, another due to system outage at school, another was corrupt, and at first I couldn’t find the fourth, since I by mistake had put it in the wrong folder 😀 . Had not rm -r got stuck on a write-protected file, the fourth would have been eaten since that folder was mounted via sshfs in my ~ . I’m a lot more careful about that kind of stuff since.
undelete files on ext4
My mother has placed some important files on her /tmp per accident. Now, of course, they are gone. This happened yesterday (2 boots of the machine since) I want to try to undelete the files. They were on /tmp, which was on the same partition as the rest of / , so I need a tool that runs on a mounted system (or maybe I could use a livecd . ) Right now, I am trying testdisk on a systemrescuecd that I just downloaded. I can get some files from /tmp, but not all. (is it the right tool ? What exactly are those «red» files ? are only some of them recoverable ?)
The best solution is probably a backup and the next best solution for someone who is technically less apt than you perhaps btrfs with frequent snapshots. Packages like restic , rdiff-backup , duplicity or backintime-qt may also be of interest. None of this is going to help you in retrospect, but perhaps this comment helps future visitors.
For me extundelete segments, while testdisk whips out a list of differences. Now to see if it can get the files back.
5 Answers 5
First unmount ( umount ) the file system where the files have been deleted.
Then read the chapter What to do if you’ve deleted a file.
You can install extundelete from classic Ubuntu repository:
sudo apt-get install extundelete Or better, you can download the latest version and compile it:
cd ~/Download tar -xf extundelete-*.*.*-.tar.bz2 #Replace *.*.* by the version cd extundelete-*.*.* sudo apt-get install e2fslibs-dev #Required for compilation ./configure make sudo make install extundelete --version #Should be your *.*.* version Example of usage: restore all deleted files from directory Images into new created directory restore
sudo extundelete --restore-directory Images/ -o restore /dev/sda3 Bad news if you see your file XXXX within the following format:
Unable to restore inode NNN (Images/XXXX): Space has been reallocated. See all restored files (look for your file):
Backup your file(s) and remove this temporary directory restore
cp restore/Images/XXXX MY_BACKUP_DIRECTORY sudo rm -rf restore Data recovery, especially on EXT file systems, should be attempted from a live CD or other system that isn’t depending on the partition you’re undeleting from. Getting the disk unmounted or re-mounted as read only helps a great deal in the recovery effort.
Most of the time I try to create an image of the partition or disk using dd or a similar tool, so that I’m not working on the disk itself:
dd if=/dev/sd[xx] of=/media/backup_drive/recovery.img Once you have your image, you can use a tool like ext3grep to try and find the files you’re looking for. There are lots of different switches that you can try, but this might be a good start:
ext3grep --restore-file 'tmp/moms-file.txt' recovery.img The ext3grep utility also provides several different ways to search through the file system if you don’t know the name of the file. Check ext3grep —help for the various methods of searching.