65
43
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?
65
43
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?
51
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.
Press CTRL+D to send message.
Next use init 1 command to take system to a single user mode:
# init 1
Using grep (traditional UNIX way) to recover files
Use following grep syntax:
grep -b 'search-text' /dev/partition > file.txt
OR
grep -a -B[size before] -A[size after] 'text' /dev/[your_partition] > file.txt
Where,
-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.
To recover text file starting with "nixCraft" word on /dev/sda1 you can try following command:
# grep -i -a -B10 -A100 'nixCraft' /dev/sda1 > file.txt
Next use vi to see file.txt.
This method is ONLY useful if deleted file is text file. If you are using ext2 file system, try out recover command.
Found at http://www.cyberciti.biz/tips/linuxunix-recover-deleted-files.html
1This 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. – Benjamin B. – 2015-04-23T13:34:54.203
1@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. – Thomas Guyot-Sionnest – 2015-10-19T12:39:48.643
what is your_partition??? I have error: /dev/sda1: No such file or directory – coolcool1994 – 2016-10-30T03:15:50.313
@coolcool1994 I don't have this system anymore, so can't fully test. Try with just /dev/sda
and also check if you do have a partition named /dev/sda1
inside /dev
– Gabriel L. Oliveira – 2016-11-07T15:34:01.133
I have a Mac system tho. I looked it up in disk0, disk0s1, and all other disk files but was not able to find the lost file (maybe because I have overridden the file). – coolcool1994 – 2016-11-08T17:51:39.067
I'm sorry but I can't help anymore. Searching over, I've found this link [1] which may help you with the use of Time Machine or Free recovery softwares. [1] http://www.wikihow.com/Recover-Accidentally-Deleted-Files-in-OS-X
– Gabriel L. Oliveira – 2016-11-09T11:45:31.470Can I skip 2nd step # init 1
? – Qback – 2018-01-17T11:25:05.767
1@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. – Gabriel L. Oliveira – 2018-01-17T14:46:37.373
16Worth noting you CANNOT DO THIS REMOTELY single user mode turns off networking – Quinma – 2013-08-06T20:29:33.637
13
dd
and try to find the file within it (using grep
, or an editor).Edit: sometimes ddrescue
works better than dd
.
1"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? – TheLQ – 2010-07-09T07:30:35.127
1The 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. – wazoox – 2010-07-09T13:46:35.850
8
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.
1extundelete is also handy if the partition is ext3/4. However, the first thing to do is perhaps to unmount the partition. – billc.cn – 2011-07-25T02:08:31.147
5
If it's the standard rm, I hope you have a backup. The procedure to recover a deleted file would be different for each file system, if it can be done at all. Linux doesn't have a built-in "recycle bin"; once you delete a file, it's all but gone.
Any way you do it, you'll want to unplug the computer -- as soon as possible, as continuing to run the computer (even to shut it down) causes writes to the disk and increases the chance that some blocks formerly occupied by the file will be overwritten. Once you've done that, either put it in another computer, reboot off a live CD (making sure not to mount the drive unless you mount it read-only), or remove the hard drive and take it to a data recovery specialist.
5
The only correct answer is : restore your file from backup. Everybody must have a backup. For really important files, you should have two backups. You don't? Well, too bad, here's a lesson learnt ( Sorry to sound harsh, but I'm in data storage, and people don't back up until they lost some important data, that's a given fact. So yes, you look stupid, but so is nearly everybody else ).
OK, you have no backup. you must stop using the filesystem which contained the file RIGHT NOW. Any write activity may definitely hose the file data that may (only may) remain on disk.
if you made the tragic error to use only one partition as both the root filesystem and /home, that means you must boot from some other device. NOW .
If your file is of some common format ( Word file, JPG, etc), use Photorec. Photorec can retrieve most common file formats.
You can try the "ext3 undelete" method proposed previously, but you need to be comfortable with the command line, understand basic linux inner workings, etc.
If your file is of some special format, tough luck. I once wrote a Perl program to scan a drive for some special files, and it worked pretty well; but you'll need to know some programming to do that, and be quite at ease with linux too.
5
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
rm -r foo<Tab>*
, which sadly, since foo
apparently was a symlink and the only file matching this, the shell made into
rm -r foo\ foo *
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 :-D . 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.
4
Set your expectations low. If anything was written over the 'deleted' data, you will lose it.
I have done a small amount of recovery and the best tools I found were often designed towards certain formats. For example 'photorec' was great when I wanted to get tens of thousands of jpegs recovered.
Recuva has also helped me before now and might be your best choice. (Its free, don't get tricked into paying by their ads)
At the end of the day, if what you lost is important, take the drive offline and stop writing to it. Use every piece of recovery software you can find until you get your data back or it stops being worth it. If its really important, send it to professionals at a high price.
If you've had luck with a tool before, try it again seen as you're familiar with it. At the end of the day, they shouldn't be writing to disk and so you can use software until you find one that works.
2
If you have an application open which is currently reading the file, such as VLC or LibreOffice, then this terrific L&U.SO answer helped me out of this mess. Here is an alternative method for doing the same.
The general idea is to find the link in /proc/PID/fd/DESCRIPTOR_NUMBER
and copy it back to its original location. Use ps aux | grep APP_NAME
to find the PID and then ls -la /proc/PID/fd/
to find the proper DESCRIPTOR_NUMBER.
1
If it's not overwritten by other users, then you are lucky. I accidentally deleted my cpp source file and used a tool called foremost, which helped me restored 60G cpp debris from the disk. Finally, I recovered my file by assembling those debris piece by piece. I think it scans certain pattern for specific file type and traverses all the inodes on the disk to recover files! Just have a try!
1
The "correct" answer is to assume there isn't a method to reliably recover, and instead restore from backups or a cloned system or reinstall.
TestDisk is a great tool, and there are other ways of being able to salvage some data from the physical drive depending on file system and recency of deletion, but the time and pain involved can be just too great, so KEEP BACKUPS (and also test that they are valid and restorable)!
1
Here is a great document for you. You will find a load of practical tips there.
BTW, there are two groups of people:
Congratulations, you just promoted yourself to group 2. ;-)
0
You can try this script. Works nicely and meant to be used inplace of rm and im using it extensively now.
https://github.com/nateshmbhat/safe-rm
rm
0
If accidentally you have deleted the file from Linux then you can use this command:
find /root -name "search text" -type f -exec mv {} "/home" \;
in place of search text
you can put file name and can specify directory where you want to restore in place of /home
.
2Hi Santosh. Please do not add misleading links to your posts. It has been removed. – ᔕᖺᘎᕊ – 2014-07-17T13:02:11.523
-2
I had the same problem last week and I tried a lot of programs, like debugfs, photorec, ext3grep and extundelete. ext3grep was the best program to recover files. The sintax is very easy:
ext3grep image.img --restore-all
or:
ext3grep /dev/sda3 --restore-all --after date -d '2015-01-01 00:00:00' '+%s' --before `date -d ‘2015-01-02 00:00:00’ ‘+%s’
This video shows is a mini tutorial that can help you.
2
some more up-to-date answers: http://unix.stackexchange.com/questions/122305/undelete-a-just-deleted-file-on-ext4-with-extundelete
– Ben Crowell – 2014-08-25T23:47:40.037Don't use "rm" if you wish to restore the files in future .Use "rm-trash" utility instead : https://github.com/nateshmbhat/rm-trash
– Natesh bhat – 2018-11-20T14:31:13.813@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. – Jose Elera – 2013-01-21T08:23:46.073