Is there a command to recover/undelete deleted files by rm
?
rm -rf /path/to/myfile
How can I recover myfile
? If there is a tool to do this, how can I use it?
Is there a command to recover/undelete deleted files by rm
?
rm -rf /path/to/myfile
How can I recover myfile
? If there is a tool to do this, how can I use it?
The link someone provided in the comments is likely your best chance.
Linux debugfs Hack: Undelete Files
That write-up though looking a little intimidating is actually fairly straight forward to follow. In general the steps are as follows:
Use debugfs to view a filesystems log
$ debugfs -w /dev/mapper/wks01-root
At the debugfs prompt
debugfs: lsdel
Sample output
Inode Owner Mode Size Blocks Time deleted
23601299 0 120777 3 1/ 1 Tue Mar 13 16:17:30 2012
7536655 0 120777 3 1/ 1 Tue May 1 06:21:22 2012
2 deleted inodes found.
Run the command in debugfs
debugfs: logdump -i <7536655>
Determine files inode
...
...
....
output truncated
Fast_link_dest: bin
Blocks: (0+1): 7235938
FS block 7536642 logged at sequence 38402086, journal block 26711
(inode block for inode 7536655):
Inode: 7536655 Type: symlink Mode: 0777 Flags: 0x0 Generation: 3532221116
User: 0 Group: 0 Size: 3
File ACL: 0 Directory ACL: 0
Links: 0 Blockcount: 0
Fragment: Address: 0 Number: 0 Size: 0
ctime: 0x4f9fc732 -- Tue May 1 06:21:22 2012
atime: 0x4f9fc730 -- Tue May 1 06:21:20 2012
mtime: 0x4f9fc72f -- Tue May 1 06:21:19 2012
dtime: 0x4f9fc732 -- Tue May 1 06:21:22 2012
Fast_link_dest: bin
Blocks: (0+1): 7235938
No magic number at block 28053: end of journal.
With the above inode info run the following commands
# dd if=/dev/mapper/wks01-root of=recovered.file.001 bs=4096 count=1 skip=7235938
# file recovered.file.001
file: ASCII text, with very long lines
Files been recovered to recovered.file.001
.
If the above isn't for you I've used tools such as photorec
to recover files in the past, but it's geared for image files only. I've written about this method extensively on my blog in this article titled:
How to Recover Corrupt jpeg and mov Files from a Digital Camera's SDD Card on Fedora/CentOS/RHEL.
debugfs -w /dev/sdb2
but lsdel
sais: 0 deleted inodes found.
extundelete
is easier for ext3/4 and would probably lead to the same results.
Commented
Jun 16, 2015 at 19:54
/dev/mapper/wks01-root: No such file or directory while opening filesystem
Where did you get this /dev/mapper/wks01-root
from?
Commented
May 2, 2017 at 12:04
grep
to search in the hard-drive (maybe browse your clipboard to search a pasted line, or vim yank):grep -a -C 300 -F 'known fixed string in deleted file' /dev/sda > ~/recover
then edit ~/recover
to keep only what was your file before by editing. With by example vim editor, that will be a simple task.
Hey, if with Unix philosophy all is files, it's time to take advantage of this, no ?
-a
is meant to grep even binary data-C<NUM>
specifies lines of output context from before and after each match of the string; you can use -B<NUM>
to include lines before each match or -A<NUM>
to include lines after each match instead-F
fixed stringF
ile D
escriptorWith a bit of chances, sometimes I can recover deleted files with this :
#!/bin/bash
export LANG=C
if [[ ! $1 || $1 == -h || $1 == --help ]]; then
echo -e "Usage:\n\n\t$0 '[path/]<file name>'"
exit 1
fi
files=(
$(file 2>/dev/null /proc/*/fd/* |
grep "(deleted)'$" |
sed -r 's@(:.*broken\s+symbolic\s+link\s+to\s+.|\(deleted\).$)@ @g' |
grep "$1" |
cut -d' ' -f1
)
)
if [[ ${files[@]} ]]; then
for f in ${files[@]}; do
echo "fd $f match... Try to copy this fd to another place quickly!"
done
else
echo >&2 "No matching fd found..."
exit 2
fi
grep
based solution is very clever and worked for me, even with the file system still mounted. Thanks!
grep -av "[^[:print:]]"
Commented
Mar 28, 2017 at 19:12
What worked for me was given by arch (only applies to text files):
grep -a -C 200 -F 'Unique string in text file' /dev/sdXN
where /dev/sdXN
is the partition containing the lost file (check with mount
if unsure).
Takes a little while, but worked when I accidentally deleted some source code I hadn't commited yet!
rm data/*.json python myFile.py
instead of rm data/*.json && python myFile.py
Commented
Jun 30, 2017 at 9:03
/dev/sdXN
is for the file system, right? I found mine with df -T | awk '{print $1,$2,$NF}' | grep "^/dev"
Recovery Tools - Command Line:
testdisk
- open source, dir-structurephotorec
- open source, NTFSextundelete
- open sourceRecovery Tools - GUI:
Info:
In my personal experience, I get my data back using ufs-explorer
and photorec
.
Sources: Linuxhacks.org
Disclosure: I am the owner of Linuxhacks.org
Although this Question is solved and a few years old, I want to mention the testdisk utility.
How to recover files with testdisk is explained well in this tutorial.
To recover files run testdisk /dev/sdX
and select your partition table type. After this, select [ Advanced ] Filesystem Utils
, then choose your partition and select [Undelete]
. Now you can browse and select deleted files and copy them to another location in your filesystem.
An alternative may be using del
instead of rm
for deleting:
http://fex.belwue.de/fstools/del.html
del
has an undelete function and works with any file system.
Of course it is not a solution if you have already deleted your files with "take no prisoners" rm :-}
del
command.
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 syntax 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 is a mini tutorial that can help you.
connect drive through external interface
umount /dev/{sd*}
extundelete --restore-all /dev/{sd*}
See this link for more info: undelete a just deleted file on ext4 with extundelete.
sources to read: https://wiki.archlinux.org/title/File_recovery#TestDisk_and_PhotoRec
Ext4magic is another recovery tool for the ext3 and ext4 file system.
Be very careful:
Example without cloning the HDD:
Before beginning, check what file system you have with the above command:
$ df -Th
Filesystem Type Size Used Avail Use% Mounted on
dev devtmpfs 3,9G 0 3,9G 0% /dev
run tmpfs 3,9G 1,8M 3,9G 1% /run
/dev/sda2 ext4 458G 151G 284G 35% /
tmpfs tmpfs 3,9G 4,3M 3,9G 1% /dev/shm
tmpfs tmpfs 3,9G 56M 3,8G 2% /tmp
After you determine that you are using ext3 or ext4, go on and plug an external HDD drive and open the terminal from the external HDD
To recover all files, deleted in the last 24 hours:
ext4magic /dev/sdXY -r
To recover a directory or file:
ext4magic /dev/sda2 -f path/to/lost/file -r
The small R flag -r will only recover complete files, that were not overwritten. To also recover broken files, that were partially overwritten, use the big R flag -R. This will also restore not-deleted files and empty directories.
The default destination is ./RECOVERDIR which can be changed by adding the option -d path/to/dest/dir.
If a file exists in the destination directory, the new file is renamed with a trailing hash sign #.
To recover files deleted after 'five days ago':
ext4magic /dev/sdXY -f path/to/lost/file -a $(date -d -5days +%s) -r
ext4magic just successfully restored my deleted files (including the correct filenames!), after several other methods were not successful.
photorec
and other toolsphotorec
can recover "more than 480 file extensions (about 300 file families)". See the full list here: https://www.cgsecurity.org/wiki/File_Formats_Recovered_By_PhotoRec.
I have written detailed instructions on recovering files using it, originally posted on Ask Ubuntu here. I have now moved that portion of that answer to here below.
I used photorec
earlier today (20 Apr. 2023) to recover 192 images taking up 3.2 GB on an SD card from 2012! All images were stored to the SD card in Nov. 2012, and were subsequently deleted. The SD card has (I think) undergone multiple "reformats" since then, and photorec
still found the photos from 11 years ago! It did not, however, find the 50 photos from today that we really wanted. That stinks, but it is probably because the card is damaged from old age and wear and didn't even write the photos taken today in the first place, whereas the photos from 12 years ago were written correctly back then. So, I'm guessing that the inability of phototrec
to find the photos from today is not due to photorec, but is rather due to the hardware of the SD card and its flash memory controller. I can't be sure though.
Anyway, here are my full instructions from today!:
Tested 20 Apr. 2023 on Ubuntu 20.04 with photorec --version
PhotoRec 7.1, Data Recovery Utility, July 2019
.
This is how I got all of my .cr2 files I then needed to convert to .jpg and .png images as described in my other answer here.
Plug in your sdcard to your computer. Open the gparted GUI to see which device the card is. Ex: mine is /dev/sdb
. We need this for the next commands.
Close gparted now, or else it will block the mount from showing up in your file manager later when we run the udisksctl
command to mount the image.
Copy all bytes from the card into an image file, so that if the card permanently fails, we still have what data we could get.
# try to copy the data from the card once
time sudo ddrescue -d /dev/sdb sdcard.img ddrescue.log
# try 3 times to read any bad sectors which were previously marked by writing
# their addresses into the ddrescue.log file
time sudo ddrescue -d -r3 /dev/sdb sdcard.img ddrescue.log
Here is a sample run and output of both commands above on a 4 GB SD card:
$ time sudo ddrescue -d /dev/sdb sdcard.img ddrescue.log
[sudo] password for gabriel:
GNU ddrescue 1.23
Press Ctrl-C to interrupt
ipos: 4072 MB, non-trimmed: 0 B, current rate: 10878 kB/s
opos: 4072 MB, non-scraped: 0 B, average rate: 15785 kB/s
non-tried: 0 B, bad-sector: 0 B, error rate: 0 B/s
rescued: 4072 MB, bad areas: 0, run time: 4m 17s
pct rescued: 100.00%, read errors: 0, remaining time: n/a
time since last successful read: n/a
Finished
real 4m25.189s
user 0m1.399s
sys 0m18.838s
$ time sudo ddrescue -d -r3 /dev/sdb sdcard.img ddrescue.log
[sudo] password for gabriel:
GNU ddrescue 1.23
Press Ctrl-C to interrupt
Initial status (read from mapfile)
rescued: 4072 MB, tried: 0 B, bad-sector: 0 B, bad areas: 0
Current status
ipos: 0 B, non-trimmed: 0 B, current rate: 0 B/s
opos: 0 B, non-scraped: 0 B, average rate: 0 B/s
non-tried: 0 B, bad-sector: 0 B, error rate: 0 B/s
rescued: 4072 MB, bad areas: 0, run time: 0s
pct rescued: 100.00%, read errors: 0, remaining time: n/a
time since last successful read: n/a
Finished
real 0m5.310s
user 0m0.036s
sys 0m0.000s
Change the owner of sdcard.img
to my username and group:
sudo chown "$USER:$USER" sdcard.img
Manually eject and remove the SD card. Be sure to right-click on your SD card in your file manager GUI and go to "Eject" or "Safely remove drive" or whatever. Then, wait for the prompt which says it's okay to remove it, before removing it, or else you risk further data corruption.
Mount the sdcard.img
image we produced above. See here.
# mount the image
udisksctl loop-setup --file sdcard.img
# You will see a new disk pop up in your file manager GUI. Click on it.
# Make note of the path it goes to.
# Ex: `/media/gabriel/EOS_DIGITAL`
# Now look for that path here, and make note of the loop filesystem that
# path is mounted to!:
df -h
# Example, mine is this:
# /dev/loop13p1 3.8G 160K 3.8G 1% /media/gabriel/EOS_DIGITAL
# We will need this `/dev/loop13p1` part in the recovery process.
Now recover the data, following the instructions here: https://www.tomshardware.com/how-to/recover-deleted-files-from-any-drive-in-linux. In short:
sudo apt install testdisk
# Open the terminal GUI-like interactive program to do the recovery!
sudo photorec
# Make your selections appropriately. Choose to recover from the
# `/dev/loop13p1` image/filesystem you mounted above.
# Note: you'll have to specify an output folder too. Manually make a folder
# to store recovered images, and tell the GUI-like program to use it.
When done, you may have a bunch of .cr2 images in your specified output recovery folder.
And that brings us to my other answer here! Convert those unfriendly .cr2
images into usable .jpg
or .png
images by following the steps in that answer under the section titled "How to batch convert hundreds of .cr2 images into .jpg or .png images".
If that worked for you: the end.
Also check out the paid EaseUS tool below. I'd be willing to bet it's a more-effective product for those willing to pay for it.
There are some other alternatives listed here: https://alternativeto.net/software/easeus-data-recovery-wizard/?platform=linux
Alos, EaseUS, a paid option, has written a really great article here, mentioning 5 total Linux data recovery options, with 4 of them being free and open source and no-cost: EaseUS.com: 2023 Best Free Linux Data Recovery Software for EXT2/EXT3.
photorec
, shown above.recoverjpeg
too. Follow instructions here: https://linuxnightly.com/how-to-recover-deleted-photos-in-linux-with-recoverjpeg/. But, in my case, photorec
was able to recover 258 files, including 192 images taking up 3.2 GB, while recoverjpeg
was only able to recover 11 JPEG images taking up 19.8 MB. So photorec
is the clear winner in my case! Try both out for yourself though.Recovering files and images:
ddrescue
and stuffddrescue
: https://www.electricrcaircraftguy.com/2018/01/how-to-clone-your-hard-drive.htmlphotorec
and testdisk
wikis, by CGSecurity.org, their maker: https://www.cgsecurity.org/wiki/PhotoRecphotorec
: https://www.cgsecurity.org/wiki/File_Formats_Recovered_By_PhotoRecphotorec
tutorial here, which I firs saw in the main answer: How to Recover Corrupt jpeg and mov Files from a Digital Camera's SDD Card on Fedora/CentOS/RHELThis might save the trouble for some of you.
If you ever used gedit to edit that file, by default a copy of that file will be created.
For example let's suppose we have accidentaly deleted 'myfile.txt'.
In the folder that used to contain the file you have just deleted use these commands and you'll recover the copy from there:
ls | grep 'myfile.txt~'
With a bit of luck you'll find it and then:
cp 'myfile.txt~' 'myfile.txt'
I have recovered a file just now using this method.
Best of luck!
When you delete a file, the link count in the inode table for that file is decreased by one. In Unix, when the link count drops down to 0, the data blocks for that file are marked as free and typically, references to those data blocks are lost. I just discovered from @fedorqui's comment that there may be some way to access those blocks but that is only applicable to ext3 filesystem.
One way to preserve the files will be to write a function that will allow you to move the files to a trash area (let us say $HOME/.trash
) and recover the needed files from there. This function can be aliased to rm
. You can schedule a cron job to delete the files that have been in the trash area for a certain number of days.
Is this just outdated or have I misunderstood something?
When I have deleted a file, I can find it back in
~/.local/share/Trash/files$
It is a normal waste bin like in Windows.
rm
on the command line - which then does not get moved trash.
Commented
Sep 28, 2022 at 20:54