Unix/Linux undelete/recover deleted files
Clash Royale CLAN TAG#URR8PPP
up vote
106
down vote
favorite
Is there a command to recover/undelete deleted files by rm
?
$ rm -rf /path/to/myfile
How can I recover myfile
? If there is such a tool how can I use it?
linux data-recovery deleted-files
migrated from stackoverflow.com Jun 21 '13 at 14:26
This question came from our site for professional and enthusiast programmers.
add a comment |Â
up vote
106
down vote
favorite
Is there a command to recover/undelete deleted files by rm
?
$ rm -rf /path/to/myfile
How can I recover myfile
? If there is such a tool how can I use it?
linux data-recovery deleted-files
migrated from stackoverflow.com Jun 21 '13 at 14:26
This question came from our site for professional and enthusiast programmers.
1
cyberciti.biz/tips/⦠can help. Also it is better in Stack Exchange.
â fedorqui
Jun 21 '13 at 13:42
1. This would be better for Unix & Linux 2. Backups?
â Doorknob
Jun 21 '13 at 13:42
1
Before you do anything, mount the filesystem read-only to make sure the data is not overwritten. Also, take a look at this post: superuser.com/questions/170857/ext4-undelete-utilities.
â Smith John
Jun 21 '13 at 15:49
1
@EvanTeitelman you mean remount read-only is better than try to recover the file while it is umounted? btw, midnightcommander (mc) way, suggests umounting datarecoverypros.com/recover-linux-midnightcommander.html
â Aquarius Power
Aug 16 '15 at 3:34
1
The best solution is to think ahead and use a revision control tool.
â ctrl-alt-delor
Feb 22 at 21:47
add a comment |Â
up vote
106
down vote
favorite
up vote
106
down vote
favorite
Is there a command to recover/undelete deleted files by rm
?
$ rm -rf /path/to/myfile
How can I recover myfile
? If there is such a tool how can I use it?
linux data-recovery deleted-files
Is there a command to recover/undelete deleted files by rm
?
$ rm -rf /path/to/myfile
How can I recover myfile
? If there is such a tool how can I use it?
linux data-recovery deleted-files
edited Apr 29 '14 at 22:58
Gilles
505k1199981526
505k1199981526
asked Jun 21 '13 at 13:41
pylover
1,10551422
1,10551422
migrated from stackoverflow.com Jun 21 '13 at 14:26
This question came from our site for professional and enthusiast programmers.
migrated from stackoverflow.com Jun 21 '13 at 14:26
This question came from our site for professional and enthusiast programmers.
1
cyberciti.biz/tips/⦠can help. Also it is better in Stack Exchange.
â fedorqui
Jun 21 '13 at 13:42
1. This would be better for Unix & Linux 2. Backups?
â Doorknob
Jun 21 '13 at 13:42
1
Before you do anything, mount the filesystem read-only to make sure the data is not overwritten. Also, take a look at this post: superuser.com/questions/170857/ext4-undelete-utilities.
â Smith John
Jun 21 '13 at 15:49
1
@EvanTeitelman you mean remount read-only is better than try to recover the file while it is umounted? btw, midnightcommander (mc) way, suggests umounting datarecoverypros.com/recover-linux-midnightcommander.html
â Aquarius Power
Aug 16 '15 at 3:34
1
The best solution is to think ahead and use a revision control tool.
â ctrl-alt-delor
Feb 22 at 21:47
add a comment |Â
1
cyberciti.biz/tips/⦠can help. Also it is better in Stack Exchange.
â fedorqui
Jun 21 '13 at 13:42
1. This would be better for Unix & Linux 2. Backups?
â Doorknob
Jun 21 '13 at 13:42
1
Before you do anything, mount the filesystem read-only to make sure the data is not overwritten. Also, take a look at this post: superuser.com/questions/170857/ext4-undelete-utilities.
â Smith John
Jun 21 '13 at 15:49
1
@EvanTeitelman you mean remount read-only is better than try to recover the file while it is umounted? btw, midnightcommander (mc) way, suggests umounting datarecoverypros.com/recover-linux-midnightcommander.html
â Aquarius Power
Aug 16 '15 at 3:34
1
The best solution is to think ahead and use a revision control tool.
â ctrl-alt-delor
Feb 22 at 21:47
1
1
cyberciti.biz/tips/⦠can help. Also it is better in Stack Exchange.
â fedorqui
Jun 21 '13 at 13:42
cyberciti.biz/tips/⦠can help. Also it is better in Stack Exchange.
â fedorqui
Jun 21 '13 at 13:42
1. This would be better for Unix & Linux 2. Backups?
â Doorknob
Jun 21 '13 at 13:42
1. This would be better for Unix & Linux 2. Backups?
â Doorknob
Jun 21 '13 at 13:42
1
1
Before you do anything, mount the filesystem read-only to make sure the data is not overwritten. Also, take a look at this post: superuser.com/questions/170857/ext4-undelete-utilities.
â Smith John
Jun 21 '13 at 15:49
Before you do anything, mount the filesystem read-only to make sure the data is not overwritten. Also, take a look at this post: superuser.com/questions/170857/ext4-undelete-utilities.
â Smith John
Jun 21 '13 at 15:49
1
1
@EvanTeitelman you mean remount read-only is better than try to recover the file while it is umounted? btw, midnightcommander (mc) way, suggests umounting datarecoverypros.com/recover-linux-midnightcommander.html
â Aquarius Power
Aug 16 '15 at 3:34
@EvanTeitelman you mean remount read-only is better than try to recover the file while it is umounted? btw, midnightcommander (mc) way, suggests umounting datarecoverypros.com/recover-linux-midnightcommander.html
â Aquarius Power
Aug 16 '15 at 3:34
1
1
The best solution is to think ahead and use a revision control tool.
â ctrl-alt-delor
Feb 22 at 21:47
The best solution is to think ahead and use a revision control tool.
â ctrl-alt-delor
Feb 22 at 21:47
add a comment |Â
11 Answers
11
active
oldest
votes
up vote
59
down vote
accepted
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
.
Other options
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.
7
I tried withdebugfs -w /dev/sdb2
butlsdel
sais:0 deleted inodes found.
â rubo77
Sep 11 '13 at 7:54
5
usingextundelete
is easier for ext3/4 and would probably lead to the same results.
â eadmaster
Jun 16 '15 at 19:54
1
this worked to recover a file, but I received ��@y��U���T6 �ÃÂ��*e�0�� ��v'���T�0�<#selinuxsystem_u:object_r:rpm_var_lib_t:s0��}y��U���T6..... trying conv=ascii, conv=ibm, and conv=ebcdic yields same problem
â codyc4321
Aug 4 '15 at 18:20
1
lsdel: Filesystem not open,how to resolve it?
â AmitÃÂbha
Oct 22 '15 at 9:38
2
I get/dev/mapper/wks01-root: No such file or directory while opening filesystem
Where did you get this/dev/mapper/wks01-root
from?
â Marko Avlijaà ¡
May 2 '17 at 12:04
 |Â
show 5 more comments
up vote
24
down vote
With a bit of chances, sometimes I can recover deleted files with this script or next solution in the answer :
#!/bin/bash
if [[ ! $1 ]]; then
echo -e "Usage:nnt$0 'file name'"
exit 1
fi
f=$(ls 2>/dev/null -l /proc/*/fd/* | fgrep "$1 (deleted" | awk 'print $9')
if [[ $f ]]; then
echo "fd $f found..."
cp -v "$f" "$1"
else
echo >&2 "No fd found..."
exit 2
fi
There's another useful trick: if you know a pattern in your deleted files, type alt+sys+resuo to reboot+remount in read-only, then with a live-cd, use grep
to search in the hard-drive :
grep -a -C 500 'known pattern' /dev/sda | tee /tmp/recover
then edit /tmp/recover
to keep only what were your file(s) before.
Hey, if with unix philosophy all is files, it's time to take advantage of this, no ?
5
Yourgrep
based solution is very clever and worked for me, even with the file system still mounted. Thanks!
â wchargin
Nov 27 '14 at 20:16
I don't understand how the grep solution worked for you, it outputs only binary data. How is that useful?
â w00t
Aug 15 '16 at 0:33
1
@w00t Sure, it "only" spits out binary data. But sometimes that binary data happens to contain the ASCII bits corresponding to the file I'm looking for. I guess I don't understand the question?
â wchargin
Sep 5 '16 at 2:17
1
Script worked for me. Thanks!
â Aniket Thakur
Oct 15 '16 at 19:13
@w00t the trick is to use a search pattern that is very specific to that file. The grep command will take the 500 lines before and after each matching line, so it will still spit out a lot of irrelevant data, but with a text editor that can cope with that (e.g. Vim), it's easy to sort out the good from the bad stuff. You could also filter out all lines with nonprintable characters by piping it through another grep command:grep -av "[^[:print:]]"
â Ragnagord
Mar 28 '17 at 19:12
 |Â
show 1 more comment
up vote
9
down vote
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
Takes a little while, but worked when I accidentally deleted some source code I hadn't commited yet!
2
Very useful for programmers!. usually, we always lost our own codes.
â pylover
Jun 28 '17 at 11:30
1
tell me about it, I accidentally ranrm data/*.json python myFile.py
instead ofrm data/*.json && python myFile.py
â William Becker
Jun 30 '17 at 9:03
1
Thanks mate, you just helped me recover a text file I spent 2 hours writing at night. P.S./dev/sdXN
is for the file system, right? I found mine withdf -T | awk 'print $1,$2,$NF' | grep "^/dev"
â Alex
Apr 15 at 16:31
add a comment |Â
up vote
6
down vote
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 :-}
1
Not an answer as you have already said, but thanks for introducing thedel
command.
â pylover
Feb 12 '16 at 8:26
add a comment |Â
up vote
6
down vote
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.
add a comment |Â
up vote
5
down vote
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.
add a comment |Â
up vote
4
down vote
connect drive through external interface
- mount
umount /dev/sd*
extundelete --restore-all /dev/sd*
- results go to home folder on boot drive
- bonus points: write a GUI for this
See this link for more info: undelete a just deleted file on ext4 with extundelete.
2
Downvoters, please explain why you think extundelete is not good option?
â webminal.org
Apr 11 '15 at 6:05
1
Nice! Thanks for posting. extundelete is a new tool for me. I used this today and found it extremely helpful. Much more helpful IMO than the accepted answer. The only things I would add to this answer to improve it slightly are (1) to reiterate the instructions in some other answers that one should power down the affected computer as soon as one realizes that the files were mistakenly deleted, and (2) to boot from a liveCD or liveUSB OS like Kali Linux which includes the extundelete utility (I found that many other liveCDs like Debian Jessie do not include this utility on their install media).
â Osteoboon
Mar 13 '17 at 16:22
add a comment |Â
up vote
1
down vote
Recovery Tools - Command Line :
testdisk (3)(5)
photorec (3)
extundelete (3)
Recovery Tools - Gui :
R-Linux (2)(5)
R-Studio (1)(5)(4)
UFS Explorer (1)(5)(4)
Recovery Explorer (1)(5)(4)
Infos :
In my personal experience i get my data back using "UFS Explorer" and photorec
(1) = Not open source, not free
(2) = Not open source, free
(3) = Open source and free
(4) = Have ntfs support
(5) = Have directory structure feature
add a comment |Â
up vote
0
down vote
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.
add a comment |Â
up vote
0
down vote
I disagree that it is impossible, just very very difficult, and neither have I ever done it off Linux:
When files are deleted, they're not actually deleted. What happens is that the space that they were on the hard-drive is sort of reset, so that if the computer tries to write data there, nothing complains. Generally, the data on your hard drive you thought you deleted can be there almost a year later. Or at least, this is my experience on a Windows machine. Whether or not it works the same way from a commandline on Linux, I'm not sure, but you'd likely need a separate Live CD to open the partition like that, and there's also no guarantee the files are still there. I've done this on windows xp several times using Zero Assumption Recovery. I'm sure there's a similar tool around if you look hard enough.
Depending on the situation it may be 100% impossible. It may or may not work, but you NEVER have any guarantees.
â klutt
Jan 3 at 10:16
add a comment |Â
up vote
0
down vote
This 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!
add a comment |Â
protected by Community⦠Aug 23 '17 at 12:27
Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).
Would you like to answer one of these unanswered questions instead?
11 Answers
11
active
oldest
votes
11 Answers
11
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
59
down vote
accepted
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
.
Other options
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.
7
I tried withdebugfs -w /dev/sdb2
butlsdel
sais:0 deleted inodes found.
â rubo77
Sep 11 '13 at 7:54
5
usingextundelete
is easier for ext3/4 and would probably lead to the same results.
â eadmaster
Jun 16 '15 at 19:54
1
this worked to recover a file, but I received ��@y��U���T6 �ÃÂ��*e�0�� ��v'���T�0�<#selinuxsystem_u:object_r:rpm_var_lib_t:s0��}y��U���T6..... trying conv=ascii, conv=ibm, and conv=ebcdic yields same problem
â codyc4321
Aug 4 '15 at 18:20
1
lsdel: Filesystem not open,how to resolve it?
â AmitÃÂbha
Oct 22 '15 at 9:38
2
I get/dev/mapper/wks01-root: No such file or directory while opening filesystem
Where did you get this/dev/mapper/wks01-root
from?
â Marko Avlijaà ¡
May 2 '17 at 12:04
 |Â
show 5 more comments
up vote
59
down vote
accepted
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
.
Other options
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.
7
I tried withdebugfs -w /dev/sdb2
butlsdel
sais:0 deleted inodes found.
â rubo77
Sep 11 '13 at 7:54
5
usingextundelete
is easier for ext3/4 and would probably lead to the same results.
â eadmaster
Jun 16 '15 at 19:54
1
this worked to recover a file, but I received ��@y��U���T6 �ÃÂ��*e�0�� ��v'���T�0�<#selinuxsystem_u:object_r:rpm_var_lib_t:s0��}y��U���T6..... trying conv=ascii, conv=ibm, and conv=ebcdic yields same problem
â codyc4321
Aug 4 '15 at 18:20
1
lsdel: Filesystem not open,how to resolve it?
â AmitÃÂbha
Oct 22 '15 at 9:38
2
I get/dev/mapper/wks01-root: No such file or directory while opening filesystem
Where did you get this/dev/mapper/wks01-root
from?
â Marko Avlijaà ¡
May 2 '17 at 12:04
 |Â
show 5 more comments
up vote
59
down vote
accepted
up vote
59
down vote
accepted
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
.
Other options
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.
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
.
Other options
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.
answered Jun 21 '13 at 15:49
slmâ¦
235k65482654
235k65482654
7
I tried withdebugfs -w /dev/sdb2
butlsdel
sais:0 deleted inodes found.
â rubo77
Sep 11 '13 at 7:54
5
usingextundelete
is easier for ext3/4 and would probably lead to the same results.
â eadmaster
Jun 16 '15 at 19:54
1
this worked to recover a file, but I received ��@y��U���T6 �ÃÂ��*e�0�� ��v'���T�0�<#selinuxsystem_u:object_r:rpm_var_lib_t:s0��}y��U���T6..... trying conv=ascii, conv=ibm, and conv=ebcdic yields same problem
â codyc4321
Aug 4 '15 at 18:20
1
lsdel: Filesystem not open,how to resolve it?
â AmitÃÂbha
Oct 22 '15 at 9:38
2
I get/dev/mapper/wks01-root: No such file or directory while opening filesystem
Where did you get this/dev/mapper/wks01-root
from?
â Marko Avlijaà ¡
May 2 '17 at 12:04
 |Â
show 5 more comments
7
I tried withdebugfs -w /dev/sdb2
butlsdel
sais:0 deleted inodes found.
â rubo77
Sep 11 '13 at 7:54
5
usingextundelete
is easier for ext3/4 and would probably lead to the same results.
â eadmaster
Jun 16 '15 at 19:54
1
this worked to recover a file, but I received ��@y��U���T6 �ÃÂ��*e�0�� ��v'���T�0�<#selinuxsystem_u:object_r:rpm_var_lib_t:s0��}y��U���T6..... trying conv=ascii, conv=ibm, and conv=ebcdic yields same problem
â codyc4321
Aug 4 '15 at 18:20
1
lsdel: Filesystem not open,how to resolve it?
â AmitÃÂbha
Oct 22 '15 at 9:38
2
I get/dev/mapper/wks01-root: No such file or directory while opening filesystem
Where did you get this/dev/mapper/wks01-root
from?
â Marko Avlijaà ¡
May 2 '17 at 12:04
7
7
I tried with
debugfs -w /dev/sdb2
but lsdel
sais: 0 deleted inodes found.
â rubo77
Sep 11 '13 at 7:54
I tried with
debugfs -w /dev/sdb2
but lsdel
sais: 0 deleted inodes found.
â rubo77
Sep 11 '13 at 7:54
5
5
using
extundelete
is easier for ext3/4 and would probably lead to the same results.â eadmaster
Jun 16 '15 at 19:54
using
extundelete
is easier for ext3/4 and would probably lead to the same results.â eadmaster
Jun 16 '15 at 19:54
1
1
this worked to recover a file, but I received ��@y��U���T6 �ÃÂ��*e�0�� ��v'���T�0�<#selinuxsystem_u:object_r:rpm_var_lib_t:s0��}y��U���T6..... trying conv=ascii, conv=ibm, and conv=ebcdic yields same problem
â codyc4321
Aug 4 '15 at 18:20
this worked to recover a file, but I received ��@y��U���T6 �ÃÂ��*e�0�� ��v'���T�0�<#selinuxsystem_u:object_r:rpm_var_lib_t:s0��}y��U���T6..... trying conv=ascii, conv=ibm, and conv=ebcdic yields same problem
â codyc4321
Aug 4 '15 at 18:20
1
1
lsdel: Filesystem not open,how to resolve it?
â AmitÃÂbha
Oct 22 '15 at 9:38
lsdel: Filesystem not open,how to resolve it?
â AmitÃÂbha
Oct 22 '15 at 9:38
2
2
I get
/dev/mapper/wks01-root: No such file or directory while opening filesystem
Where did you get this /dev/mapper/wks01-root
from?â Marko Avlijaà ¡
May 2 '17 at 12:04
I get
/dev/mapper/wks01-root: No such file or directory while opening filesystem
Where did you get this /dev/mapper/wks01-root
from?â Marko Avlijaà ¡
May 2 '17 at 12:04
 |Â
show 5 more comments
up vote
24
down vote
With a bit of chances, sometimes I can recover deleted files with this script or next solution in the answer :
#!/bin/bash
if [[ ! $1 ]]; then
echo -e "Usage:nnt$0 'file name'"
exit 1
fi
f=$(ls 2>/dev/null -l /proc/*/fd/* | fgrep "$1 (deleted" | awk 'print $9')
if [[ $f ]]; then
echo "fd $f found..."
cp -v "$f" "$1"
else
echo >&2 "No fd found..."
exit 2
fi
There's another useful trick: if you know a pattern in your deleted files, type alt+sys+resuo to reboot+remount in read-only, then with a live-cd, use grep
to search in the hard-drive :
grep -a -C 500 'known pattern' /dev/sda | tee /tmp/recover
then edit /tmp/recover
to keep only what were your file(s) before.
Hey, if with unix philosophy all is files, it's time to take advantage of this, no ?
5
Yourgrep
based solution is very clever and worked for me, even with the file system still mounted. Thanks!
â wchargin
Nov 27 '14 at 20:16
I don't understand how the grep solution worked for you, it outputs only binary data. How is that useful?
â w00t
Aug 15 '16 at 0:33
1
@w00t Sure, it "only" spits out binary data. But sometimes that binary data happens to contain the ASCII bits corresponding to the file I'm looking for. I guess I don't understand the question?
â wchargin
Sep 5 '16 at 2:17
1
Script worked for me. Thanks!
â Aniket Thakur
Oct 15 '16 at 19:13
@w00t the trick is to use a search pattern that is very specific to that file. The grep command will take the 500 lines before and after each matching line, so it will still spit out a lot of irrelevant data, but with a text editor that can cope with that (e.g. Vim), it's easy to sort out the good from the bad stuff. You could also filter out all lines with nonprintable characters by piping it through another grep command:grep -av "[^[:print:]]"
â Ragnagord
Mar 28 '17 at 19:12
 |Â
show 1 more comment
up vote
24
down vote
With a bit of chances, sometimes I can recover deleted files with this script or next solution in the answer :
#!/bin/bash
if [[ ! $1 ]]; then
echo -e "Usage:nnt$0 'file name'"
exit 1
fi
f=$(ls 2>/dev/null -l /proc/*/fd/* | fgrep "$1 (deleted" | awk 'print $9')
if [[ $f ]]; then
echo "fd $f found..."
cp -v "$f" "$1"
else
echo >&2 "No fd found..."
exit 2
fi
There's another useful trick: if you know a pattern in your deleted files, type alt+sys+resuo to reboot+remount in read-only, then with a live-cd, use grep
to search in the hard-drive :
grep -a -C 500 'known pattern' /dev/sda | tee /tmp/recover
then edit /tmp/recover
to keep only what were your file(s) before.
Hey, if with unix philosophy all is files, it's time to take advantage of this, no ?
5
Yourgrep
based solution is very clever and worked for me, even with the file system still mounted. Thanks!
â wchargin
Nov 27 '14 at 20:16
I don't understand how the grep solution worked for you, it outputs only binary data. How is that useful?
â w00t
Aug 15 '16 at 0:33
1
@w00t Sure, it "only" spits out binary data. But sometimes that binary data happens to contain the ASCII bits corresponding to the file I'm looking for. I guess I don't understand the question?
â wchargin
Sep 5 '16 at 2:17
1
Script worked for me. Thanks!
â Aniket Thakur
Oct 15 '16 at 19:13
@w00t the trick is to use a search pattern that is very specific to that file. The grep command will take the 500 lines before and after each matching line, so it will still spit out a lot of irrelevant data, but with a text editor that can cope with that (e.g. Vim), it's easy to sort out the good from the bad stuff. You could also filter out all lines with nonprintable characters by piping it through another grep command:grep -av "[^[:print:]]"
â Ragnagord
Mar 28 '17 at 19:12
 |Â
show 1 more comment
up vote
24
down vote
up vote
24
down vote
With a bit of chances, sometimes I can recover deleted files with this script or next solution in the answer :
#!/bin/bash
if [[ ! $1 ]]; then
echo -e "Usage:nnt$0 'file name'"
exit 1
fi
f=$(ls 2>/dev/null -l /proc/*/fd/* | fgrep "$1 (deleted" | awk 'print $9')
if [[ $f ]]; then
echo "fd $f found..."
cp -v "$f" "$1"
else
echo >&2 "No fd found..."
exit 2
fi
There's another useful trick: if you know a pattern in your deleted files, type alt+sys+resuo to reboot+remount in read-only, then with a live-cd, use grep
to search in the hard-drive :
grep -a -C 500 'known pattern' /dev/sda | tee /tmp/recover
then edit /tmp/recover
to keep only what were your file(s) before.
Hey, if with unix philosophy all is files, it's time to take advantage of this, no ?
With a bit of chances, sometimes I can recover deleted files with this script or next solution in the answer :
#!/bin/bash
if [[ ! $1 ]]; then
echo -e "Usage:nnt$0 'file name'"
exit 1
fi
f=$(ls 2>/dev/null -l /proc/*/fd/* | fgrep "$1 (deleted" | awk 'print $9')
if [[ $f ]]; then
echo "fd $f found..."
cp -v "$f" "$1"
else
echo >&2 "No fd found..."
exit 2
fi
There's another useful trick: if you know a pattern in your deleted files, type alt+sys+resuo to reboot+remount in read-only, then with a live-cd, use grep
to search in the hard-drive :
grep -a -C 500 'known pattern' /dev/sda | tee /tmp/recover
then edit /tmp/recover
to keep only what were your file(s) before.
Hey, if with unix philosophy all is files, it's time to take advantage of this, no ?
edited Feb 22 at 21:45
answered Nov 3 '13 at 19:16
Gilles Quenot
15.3k13448
15.3k13448
5
Yourgrep
based solution is very clever and worked for me, even with the file system still mounted. Thanks!
â wchargin
Nov 27 '14 at 20:16
I don't understand how the grep solution worked for you, it outputs only binary data. How is that useful?
â w00t
Aug 15 '16 at 0:33
1
@w00t Sure, it "only" spits out binary data. But sometimes that binary data happens to contain the ASCII bits corresponding to the file I'm looking for. I guess I don't understand the question?
â wchargin
Sep 5 '16 at 2:17
1
Script worked for me. Thanks!
â Aniket Thakur
Oct 15 '16 at 19:13
@w00t the trick is to use a search pattern that is very specific to that file. The grep command will take the 500 lines before and after each matching line, so it will still spit out a lot of irrelevant data, but with a text editor that can cope with that (e.g. Vim), it's easy to sort out the good from the bad stuff. You could also filter out all lines with nonprintable characters by piping it through another grep command:grep -av "[^[:print:]]"
â Ragnagord
Mar 28 '17 at 19:12
 |Â
show 1 more comment
5
Yourgrep
based solution is very clever and worked for me, even with the file system still mounted. Thanks!
â wchargin
Nov 27 '14 at 20:16
I don't understand how the grep solution worked for you, it outputs only binary data. How is that useful?
â w00t
Aug 15 '16 at 0:33
1
@w00t Sure, it "only" spits out binary data. But sometimes that binary data happens to contain the ASCII bits corresponding to the file I'm looking for. I guess I don't understand the question?
â wchargin
Sep 5 '16 at 2:17
1
Script worked for me. Thanks!
â Aniket Thakur
Oct 15 '16 at 19:13
@w00t the trick is to use a search pattern that is very specific to that file. The grep command will take the 500 lines before and after each matching line, so it will still spit out a lot of irrelevant data, but with a text editor that can cope with that (e.g. Vim), it's easy to sort out the good from the bad stuff. You could also filter out all lines with nonprintable characters by piping it through another grep command:grep -av "[^[:print:]]"
â Ragnagord
Mar 28 '17 at 19:12
5
5
Your
grep
based solution is very clever and worked for me, even with the file system still mounted. Thanks!â wchargin
Nov 27 '14 at 20:16
Your
grep
based solution is very clever and worked for me, even with the file system still mounted. Thanks!â wchargin
Nov 27 '14 at 20:16
I don't understand how the grep solution worked for you, it outputs only binary data. How is that useful?
â w00t
Aug 15 '16 at 0:33
I don't understand how the grep solution worked for you, it outputs only binary data. How is that useful?
â w00t
Aug 15 '16 at 0:33
1
1
@w00t Sure, it "only" spits out binary data. But sometimes that binary data happens to contain the ASCII bits corresponding to the file I'm looking for. I guess I don't understand the question?
â wchargin
Sep 5 '16 at 2:17
@w00t Sure, it "only" spits out binary data. But sometimes that binary data happens to contain the ASCII bits corresponding to the file I'm looking for. I guess I don't understand the question?
â wchargin
Sep 5 '16 at 2:17
1
1
Script worked for me. Thanks!
â Aniket Thakur
Oct 15 '16 at 19:13
Script worked for me. Thanks!
â Aniket Thakur
Oct 15 '16 at 19:13
@w00t the trick is to use a search pattern that is very specific to that file. The grep command will take the 500 lines before and after each matching line, so it will still spit out a lot of irrelevant data, but with a text editor that can cope with that (e.g. Vim), it's easy to sort out the good from the bad stuff. You could also filter out all lines with nonprintable characters by piping it through another grep command:
grep -av "[^[:print:]]"
â Ragnagord
Mar 28 '17 at 19:12
@w00t the trick is to use a search pattern that is very specific to that file. The grep command will take the 500 lines before and after each matching line, so it will still spit out a lot of irrelevant data, but with a text editor that can cope with that (e.g. Vim), it's easy to sort out the good from the bad stuff. You could also filter out all lines with nonprintable characters by piping it through another grep command:
grep -av "[^[:print:]]"
â Ragnagord
Mar 28 '17 at 19:12
 |Â
show 1 more comment
up vote
9
down vote
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
Takes a little while, but worked when I accidentally deleted some source code I hadn't commited yet!
2
Very useful for programmers!. usually, we always lost our own codes.
â pylover
Jun 28 '17 at 11:30
1
tell me about it, I accidentally ranrm data/*.json python myFile.py
instead ofrm data/*.json && python myFile.py
â William Becker
Jun 30 '17 at 9:03
1
Thanks mate, you just helped me recover a text file I spent 2 hours writing at night. P.S./dev/sdXN
is for the file system, right? I found mine withdf -T | awk 'print $1,$2,$NF' | grep "^/dev"
â Alex
Apr 15 at 16:31
add a comment |Â
up vote
9
down vote
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
Takes a little while, but worked when I accidentally deleted some source code I hadn't commited yet!
2
Very useful for programmers!. usually, we always lost our own codes.
â pylover
Jun 28 '17 at 11:30
1
tell me about it, I accidentally ranrm data/*.json python myFile.py
instead ofrm data/*.json && python myFile.py
â William Becker
Jun 30 '17 at 9:03
1
Thanks mate, you just helped me recover a text file I spent 2 hours writing at night. P.S./dev/sdXN
is for the file system, right? I found mine withdf -T | awk 'print $1,$2,$NF' | grep "^/dev"
â Alex
Apr 15 at 16:31
add a comment |Â
up vote
9
down vote
up vote
9
down vote
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
Takes a little while, but worked when I accidentally deleted some source code I hadn't commited yet!
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
Takes a little while, but worked when I accidentally deleted some source code I hadn't commited yet!
answered Jun 28 '17 at 11:12
William Becker
9111
9111
2
Very useful for programmers!. usually, we always lost our own codes.
â pylover
Jun 28 '17 at 11:30
1
tell me about it, I accidentally ranrm data/*.json python myFile.py
instead ofrm data/*.json && python myFile.py
â William Becker
Jun 30 '17 at 9:03
1
Thanks mate, you just helped me recover a text file I spent 2 hours writing at night. P.S./dev/sdXN
is for the file system, right? I found mine withdf -T | awk 'print $1,$2,$NF' | grep "^/dev"
â Alex
Apr 15 at 16:31
add a comment |Â
2
Very useful for programmers!. usually, we always lost our own codes.
â pylover
Jun 28 '17 at 11:30
1
tell me about it, I accidentally ranrm data/*.json python myFile.py
instead ofrm data/*.json && python myFile.py
â William Becker
Jun 30 '17 at 9:03
1
Thanks mate, you just helped me recover a text file I spent 2 hours writing at night. P.S./dev/sdXN
is for the file system, right? I found mine withdf -T | awk 'print $1,$2,$NF' | grep "^/dev"
â Alex
Apr 15 at 16:31
2
2
Very useful for programmers!. usually, we always lost our own codes.
â pylover
Jun 28 '17 at 11:30
Very useful for programmers!. usually, we always lost our own codes.
â pylover
Jun 28 '17 at 11:30
1
1
tell me about it, I accidentally ran
rm data/*.json python myFile.py
instead of rm data/*.json && python myFile.py
â William Becker
Jun 30 '17 at 9:03
tell me about it, I accidentally ran
rm data/*.json python myFile.py
instead of rm data/*.json && python myFile.py
â William Becker
Jun 30 '17 at 9:03
1
1
Thanks mate, you just helped me recover a text file I spent 2 hours writing at night. P.S.
/dev/sdXN
is for the file system, right? I found mine with df -T | awk 'print $1,$2,$NF' | grep "^/dev"
â Alex
Apr 15 at 16:31
Thanks mate, you just helped me recover a text file I spent 2 hours writing at night. P.S.
/dev/sdXN
is for the file system, right? I found mine with df -T | awk 'print $1,$2,$NF' | grep "^/dev"
â Alex
Apr 15 at 16:31
add a comment |Â
up vote
6
down vote
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 :-}
1
Not an answer as you have already said, but thanks for introducing thedel
command.
â pylover
Feb 12 '16 at 8:26
add a comment |Â
up vote
6
down vote
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 :-}
1
Not an answer as you have already said, but thanks for introducing thedel
command.
â pylover
Feb 12 '16 at 8:26
add a comment |Â
up vote
6
down vote
up vote
6
down vote
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 :-}
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 :-}
edited Feb 10 '16 at 14:27
don_crissti
46.5k15124153
46.5k15124153
answered Feb 10 '16 at 14:08
Framstag
9913
9913
1
Not an answer as you have already said, but thanks for introducing thedel
command.
â pylover
Feb 12 '16 at 8:26
add a comment |Â
1
Not an answer as you have already said, but thanks for introducing thedel
command.
â pylover
Feb 12 '16 at 8:26
1
1
Not an answer as you have already said, but thanks for introducing the
del
command.â pylover
Feb 12 '16 at 8:26
Not an answer as you have already said, but thanks for introducing the
del
command.â pylover
Feb 12 '16 at 8:26
add a comment |Â
up vote
6
down vote
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.
add a comment |Â
up vote
6
down vote
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.
add a comment |Â
up vote
6
down vote
up vote
6
down vote
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.
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.
edited Aug 4 '17 at 18:27
answered Aug 2 '17 at 7:57
S. Wilhelm
6113
6113
add a comment |Â
add a comment |Â
up vote
5
down vote
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.
add a comment |Â
up vote
5
down vote
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.
add a comment |Â
up vote
5
down vote
up vote
5
down vote
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.
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.
edited Oct 19 '15 at 13:02
pylover
1,10551422
1,10551422
answered Oct 19 '15 at 12:35
Juan
5111
5111
add a comment |Â
add a comment |Â
up vote
4
down vote
connect drive through external interface
- mount
umount /dev/sd*
extundelete --restore-all /dev/sd*
- results go to home folder on boot drive
- bonus points: write a GUI for this
See this link for more info: undelete a just deleted file on ext4 with extundelete.
2
Downvoters, please explain why you think extundelete is not good option?
â webminal.org
Apr 11 '15 at 6:05
1
Nice! Thanks for posting. extundelete is a new tool for me. I used this today and found it extremely helpful. Much more helpful IMO than the accepted answer. The only things I would add to this answer to improve it slightly are (1) to reiterate the instructions in some other answers that one should power down the affected computer as soon as one realizes that the files were mistakenly deleted, and (2) to boot from a liveCD or liveUSB OS like Kali Linux which includes the extundelete utility (I found that many other liveCDs like Debian Jessie do not include this utility on their install media).
â Osteoboon
Mar 13 '17 at 16:22
add a comment |Â
up vote
4
down vote
connect drive through external interface
- mount
umount /dev/sd*
extundelete --restore-all /dev/sd*
- results go to home folder on boot drive
- bonus points: write a GUI for this
See this link for more info: undelete a just deleted file on ext4 with extundelete.
2
Downvoters, please explain why you think extundelete is not good option?
â webminal.org
Apr 11 '15 at 6:05
1
Nice! Thanks for posting. extundelete is a new tool for me. I used this today and found it extremely helpful. Much more helpful IMO than the accepted answer. The only things I would add to this answer to improve it slightly are (1) to reiterate the instructions in some other answers that one should power down the affected computer as soon as one realizes that the files were mistakenly deleted, and (2) to boot from a liveCD or liveUSB OS like Kali Linux which includes the extundelete utility (I found that many other liveCDs like Debian Jessie do not include this utility on their install media).
â Osteoboon
Mar 13 '17 at 16:22
add a comment |Â
up vote
4
down vote
up vote
4
down vote
connect drive through external interface
- mount
umount /dev/sd*
extundelete --restore-all /dev/sd*
- results go to home folder on boot drive
- bonus points: write a GUI for this
See this link for more info: undelete a just deleted file on ext4 with extundelete.
connect drive through external interface
- mount
umount /dev/sd*
extundelete --restore-all /dev/sd*
- results go to home folder on boot drive
- bonus points: write a GUI for this
See this link for more info: undelete a just deleted file on ext4 with extundelete.
edited Apr 13 '17 at 12:36
Communityâ¦
1
1
answered Oct 15 '14 at 11:37
GRZ
691
691
2
Downvoters, please explain why you think extundelete is not good option?
â webminal.org
Apr 11 '15 at 6:05
1
Nice! Thanks for posting. extundelete is a new tool for me. I used this today and found it extremely helpful. Much more helpful IMO than the accepted answer. The only things I would add to this answer to improve it slightly are (1) to reiterate the instructions in some other answers that one should power down the affected computer as soon as one realizes that the files were mistakenly deleted, and (2) to boot from a liveCD or liveUSB OS like Kali Linux which includes the extundelete utility (I found that many other liveCDs like Debian Jessie do not include this utility on their install media).
â Osteoboon
Mar 13 '17 at 16:22
add a comment |Â
2
Downvoters, please explain why you think extundelete is not good option?
â webminal.org
Apr 11 '15 at 6:05
1
Nice! Thanks for posting. extundelete is a new tool for me. I used this today and found it extremely helpful. Much more helpful IMO than the accepted answer. The only things I would add to this answer to improve it slightly are (1) to reiterate the instructions in some other answers that one should power down the affected computer as soon as one realizes that the files were mistakenly deleted, and (2) to boot from a liveCD or liveUSB OS like Kali Linux which includes the extundelete utility (I found that many other liveCDs like Debian Jessie do not include this utility on their install media).
â Osteoboon
Mar 13 '17 at 16:22
2
2
Downvoters, please explain why you think extundelete is not good option?
â webminal.org
Apr 11 '15 at 6:05
Downvoters, please explain why you think extundelete is not good option?
â webminal.org
Apr 11 '15 at 6:05
1
1
Nice! Thanks for posting. extundelete is a new tool for me. I used this today and found it extremely helpful. Much more helpful IMO than the accepted answer. The only things I would add to this answer to improve it slightly are (1) to reiterate the instructions in some other answers that one should power down the affected computer as soon as one realizes that the files were mistakenly deleted, and (2) to boot from a liveCD or liveUSB OS like Kali Linux which includes the extundelete utility (I found that many other liveCDs like Debian Jessie do not include this utility on their install media).
â Osteoboon
Mar 13 '17 at 16:22
Nice! Thanks for posting. extundelete is a new tool for me. I used this today and found it extremely helpful. Much more helpful IMO than the accepted answer. The only things I would add to this answer to improve it slightly are (1) to reiterate the instructions in some other answers that one should power down the affected computer as soon as one realizes that the files were mistakenly deleted, and (2) to boot from a liveCD or liveUSB OS like Kali Linux which includes the extundelete utility (I found that many other liveCDs like Debian Jessie do not include this utility on their install media).
â Osteoboon
Mar 13 '17 at 16:22
add a comment |Â
up vote
1
down vote
Recovery Tools - Command Line :
testdisk (3)(5)
photorec (3)
extundelete (3)
Recovery Tools - Gui :
R-Linux (2)(5)
R-Studio (1)(5)(4)
UFS Explorer (1)(5)(4)
Recovery Explorer (1)(5)(4)
Infos :
In my personal experience i get my data back using "UFS Explorer" and photorec
(1) = Not open source, not free
(2) = Not open source, free
(3) = Open source and free
(4) = Have ntfs support
(5) = Have directory structure feature
add a comment |Â
up vote
1
down vote
Recovery Tools - Command Line :
testdisk (3)(5)
photorec (3)
extundelete (3)
Recovery Tools - Gui :
R-Linux (2)(5)
R-Studio (1)(5)(4)
UFS Explorer (1)(5)(4)
Recovery Explorer (1)(5)(4)
Infos :
In my personal experience i get my data back using "UFS Explorer" and photorec
(1) = Not open source, not free
(2) = Not open source, free
(3) = Open source and free
(4) = Have ntfs support
(5) = Have directory structure feature
add a comment |Â
up vote
1
down vote
up vote
1
down vote
Recovery Tools - Command Line :
testdisk (3)(5)
photorec (3)
extundelete (3)
Recovery Tools - Gui :
R-Linux (2)(5)
R-Studio (1)(5)(4)
UFS Explorer (1)(5)(4)
Recovery Explorer (1)(5)(4)
Infos :
In my personal experience i get my data back using "UFS Explorer" and photorec
(1) = Not open source, not free
(2) = Not open source, free
(3) = Open source and free
(4) = Have ntfs support
(5) = Have directory structure feature
Recovery Tools - Command Line :
testdisk (3)(5)
photorec (3)
extundelete (3)
Recovery Tools - Gui :
R-Linux (2)(5)
R-Studio (1)(5)(4)
UFS Explorer (1)(5)(4)
Recovery Explorer (1)(5)(4)
Infos :
In my personal experience i get my data back using "UFS Explorer" and photorec
(1) = Not open source, not free
(2) = Not open source, free
(3) = Open source and free
(4) = Have ntfs support
(5) = Have directory structure feature
answered Jun 10 at 4:21
intika
1605
1605
add a comment |Â
add a comment |Â
up vote
0
down vote
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.
add a comment |Â
up vote
0
down vote
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.
add a comment |Â
up vote
0
down vote
up vote
0
down vote
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.
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.
answered Jun 21 '13 at 14:46
unxnut
3,3422918
3,3422918
add a comment |Â
add a comment |Â
up vote
0
down vote
I disagree that it is impossible, just very very difficult, and neither have I ever done it off Linux:
When files are deleted, they're not actually deleted. What happens is that the space that they were on the hard-drive is sort of reset, so that if the computer tries to write data there, nothing complains. Generally, the data on your hard drive you thought you deleted can be there almost a year later. Or at least, this is my experience on a Windows machine. Whether or not it works the same way from a commandline on Linux, I'm not sure, but you'd likely need a separate Live CD to open the partition like that, and there's also no guarantee the files are still there. I've done this on windows xp several times using Zero Assumption Recovery. I'm sure there's a similar tool around if you look hard enough.
Depending on the situation it may be 100% impossible. It may or may not work, but you NEVER have any guarantees.
â klutt
Jan 3 at 10:16
add a comment |Â
up vote
0
down vote
I disagree that it is impossible, just very very difficult, and neither have I ever done it off Linux:
When files are deleted, they're not actually deleted. What happens is that the space that they were on the hard-drive is sort of reset, so that if the computer tries to write data there, nothing complains. Generally, the data on your hard drive you thought you deleted can be there almost a year later. Or at least, this is my experience on a Windows machine. Whether or not it works the same way from a commandline on Linux, I'm not sure, but you'd likely need a separate Live CD to open the partition like that, and there's also no guarantee the files are still there. I've done this on windows xp several times using Zero Assumption Recovery. I'm sure there's a similar tool around if you look hard enough.
Depending on the situation it may be 100% impossible. It may or may not work, but you NEVER have any guarantees.
â klutt
Jan 3 at 10:16
add a comment |Â
up vote
0
down vote
up vote
0
down vote
I disagree that it is impossible, just very very difficult, and neither have I ever done it off Linux:
When files are deleted, they're not actually deleted. What happens is that the space that they were on the hard-drive is sort of reset, so that if the computer tries to write data there, nothing complains. Generally, the data on your hard drive you thought you deleted can be there almost a year later. Or at least, this is my experience on a Windows machine. Whether or not it works the same way from a commandline on Linux, I'm not sure, but you'd likely need a separate Live CD to open the partition like that, and there's also no guarantee the files are still there. I've done this on windows xp several times using Zero Assumption Recovery. I'm sure there's a similar tool around if you look hard enough.
I disagree that it is impossible, just very very difficult, and neither have I ever done it off Linux:
When files are deleted, they're not actually deleted. What happens is that the space that they were on the hard-drive is sort of reset, so that if the computer tries to write data there, nothing complains. Generally, the data on your hard drive you thought you deleted can be there almost a year later. Or at least, this is my experience on a Windows machine. Whether or not it works the same way from a commandline on Linux, I'm not sure, but you'd likely need a separate Live CD to open the partition like that, and there's also no guarantee the files are still there. I've done this on windows xp several times using Zero Assumption Recovery. I'm sure there's a similar tool around if you look hard enough.
answered Jun 21 '13 at 14:51
Roguebantha
172
172
Depending on the situation it may be 100% impossible. It may or may not work, but you NEVER have any guarantees.
â klutt
Jan 3 at 10:16
add a comment |Â
Depending on the situation it may be 100% impossible. It may or may not work, but you NEVER have any guarantees.
â klutt
Jan 3 at 10:16
Depending on the situation it may be 100% impossible. It may or may not work, but you NEVER have any guarantees.
â klutt
Jan 3 at 10:16
Depending on the situation it may be 100% impossible. It may or may not work, but you NEVER have any guarantees.
â klutt
Jan 3 at 10:16
add a comment |Â
up vote
0
down vote
This 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!
add a comment |Â
up vote
0
down vote
This 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!
add a comment |Â
up vote
0
down vote
up vote
0
down vote
This 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!
This 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!
answered Sep 30 '14 at 19:08
NTT
172
172
add a comment |Â
add a comment |Â
protected by Community⦠Aug 23 '17 at 12:27
Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).
Would you like to answer one of these unanswered questions instead?
1
cyberciti.biz/tips/⦠can help. Also it is better in Stack Exchange.
â fedorqui
Jun 21 '13 at 13:42
1. This would be better for Unix & Linux 2. Backups?
â Doorknob
Jun 21 '13 at 13:42
1
Before you do anything, mount the filesystem read-only to make sure the data is not overwritten. Also, take a look at this post: superuser.com/questions/170857/ext4-undelete-utilities.
â Smith John
Jun 21 '13 at 15:49
1
@EvanTeitelman you mean remount read-only is better than try to recover the file while it is umounted? btw, midnightcommander (mc) way, suggests umounting datarecoverypros.com/recover-linux-midnightcommander.html
â Aquarius Power
Aug 16 '15 at 3:34
1
The best solution is to think ahead and use a revision control tool.
â ctrl-alt-delor
Feb 22 at 21:47