Unix/Linux undelete/recover deleted files

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
106
down vote

favorite
76












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?







share|improve this question














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














up vote
106
down vote

favorite
76












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?







share|improve this question














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












up vote
106
down vote

favorite
76









up vote
106
down vote

favorite
76






76





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?







share|improve this question














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?









share|improve this question













share|improve this question




share|improve this question








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












  • 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










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:




  1. Use debugfs to view a filesystems log



    $ debugfs -w /dev/mapper/wks01-root



  2. At the debugfs prompt



    debugfs: lsdel



  3. 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.



  4. Run the command in debugfs



    debugfs: logdump -i <7536655>



  5. 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.



  6. 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.






share|improve this answer
















  • 7




    I tried with debugfs -w /dev/sdb2 but lsdel sais: 0 deleted inodes found.
    – rubo77
    Sep 11 '13 at 7:54







  • 5




    using extundelete 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

















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 ?






share|improve this answer


















  • 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










  • 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


















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!






share|improve this answer
















  • 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 ran rm data/*.json python myFile.py instead of rm 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 with df -T | awk 'print $1,$2,$NF' | grep "^/dev"
    – Alex
    Apr 15 at 16:31

















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 :-}






share|improve this answer


















  • 1




    Not an answer as you have already said, but thanks for introducing the del command.
    – pylover
    Feb 12 '16 at 8:26

















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.






share|improve this answer





























    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.






    share|improve this answer





























      up vote
      4
      down vote













      connect drive through external interface



      1. mount

      2. umount /dev/sd*

      3. extundelete --restore-all /dev/sd*

      4. results go to home folder on boot drive

      5. bonus points: write a GUI for this

      See this link for more info: undelete a just deleted file on ext4 with extundelete.






      share|improve this answer


















      • 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

















      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






      share|improve this answer



























        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.






        share|improve this answer



























          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.






          share|improve this answer




















          • 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

















          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!






          share|improve this answer



















            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:




            1. Use debugfs to view a filesystems log



              $ debugfs -w /dev/mapper/wks01-root



            2. At the debugfs prompt



              debugfs: lsdel



            3. 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.



            4. Run the command in debugfs



              debugfs: logdump -i <7536655>



            5. 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.



            6. 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.






            share|improve this answer
















            • 7




              I tried with debugfs -w /dev/sdb2 but lsdel sais: 0 deleted inodes found.
              – rubo77
              Sep 11 '13 at 7:54







            • 5




              using extundelete 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














            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:




            1. Use debugfs to view a filesystems log



              $ debugfs -w /dev/mapper/wks01-root



            2. At the debugfs prompt



              debugfs: lsdel



            3. 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.



            4. Run the command in debugfs



              debugfs: logdump -i <7536655>



            5. 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.



            6. 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.






            share|improve this answer
















            • 7




              I tried with debugfs -w /dev/sdb2 but lsdel sais: 0 deleted inodes found.
              – rubo77
              Sep 11 '13 at 7:54







            • 5




              using extundelete 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












            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:




            1. Use debugfs to view a filesystems log



              $ debugfs -w /dev/mapper/wks01-root



            2. At the debugfs prompt



              debugfs: lsdel



            3. 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.



            4. Run the command in debugfs



              debugfs: logdump -i <7536655>



            5. 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.



            6. 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.






            share|improve this answer












            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:




            1. Use debugfs to view a filesystems log



              $ debugfs -w /dev/mapper/wks01-root



            2. At the debugfs prompt



              debugfs: lsdel



            3. 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.



            4. Run the command in debugfs



              debugfs: logdump -i <7536655>



            5. 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.



            6. 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.







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered Jun 21 '13 at 15:49









            slm♦

            235k65482654




            235k65482654







            • 7




              I tried with debugfs -w /dev/sdb2 but lsdel sais: 0 deleted inodes found.
              – rubo77
              Sep 11 '13 at 7:54







            • 5




              using extundelete 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




              I tried with debugfs -w /dev/sdb2 but lsdel sais: 0 deleted inodes found.
              – rubo77
              Sep 11 '13 at 7:54







            • 5




              using extundelete 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












            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 ?






            share|improve this answer


















            • 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










            • 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















            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 ?






            share|improve this answer


















            • 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










            • 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













            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 ?






            share|improve this answer














            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 ?







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Feb 22 at 21:45

























            answered Nov 3 '13 at 19:16









            Gilles Quenot

            15.3k13448




            15.3k13448







            • 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










            • 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




              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






            • 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











            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!






            share|improve this answer
















            • 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 ran rm data/*.json python myFile.py instead of rm 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 with df -T | awk 'print $1,$2,$NF' | grep "^/dev"
              – Alex
              Apr 15 at 16:31














            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!






            share|improve this answer
















            • 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 ran rm data/*.json python myFile.py instead of rm 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 with df -T | awk 'print $1,$2,$NF' | grep "^/dev"
              – Alex
              Apr 15 at 16:31












            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!






            share|improve this answer












            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!







            share|improve this answer












            share|improve this answer



            share|improve this answer










            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 ran rm data/*.json python myFile.py instead of rm 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 with df -T | awk 'print $1,$2,$NF' | grep "^/dev"
              – Alex
              Apr 15 at 16:31












            • 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 ran rm data/*.json python myFile.py instead of rm 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 with df -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










            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 :-}






            share|improve this answer


















            • 1




              Not an answer as you have already said, but thanks for introducing the del command.
              – pylover
              Feb 12 '16 at 8:26














            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 :-}






            share|improve this answer


















            • 1




              Not an answer as you have already said, but thanks for introducing the del command.
              – pylover
              Feb 12 '16 at 8:26












            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 :-}






            share|improve this answer














            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 :-}







            share|improve this answer














            share|improve this answer



            share|improve this answer








            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 the del command.
              – pylover
              Feb 12 '16 at 8:26












            • 1




              Not an answer as you have already said, but thanks for introducing the del 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










            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.






            share|improve this answer


























              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.






              share|improve this answer
























                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.






                share|improve this answer














                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.







                share|improve this answer














                share|improve this answer



                share|improve this answer








                edited Aug 4 '17 at 18:27

























                answered Aug 2 '17 at 7:57









                S. Wilhelm

                6113




                6113




















                    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.






                    share|improve this answer


























                      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.






                      share|improve this answer
























                        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.






                        share|improve this answer














                        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.







                        share|improve this answer














                        share|improve this answer



                        share|improve this answer








                        edited Oct 19 '15 at 13:02









                        pylover

                        1,10551422




                        1,10551422










                        answered Oct 19 '15 at 12:35









                        Juan

                        5111




                        5111




















                            up vote
                            4
                            down vote













                            connect drive through external interface



                            1. mount

                            2. umount /dev/sd*

                            3. extundelete --restore-all /dev/sd*

                            4. results go to home folder on boot drive

                            5. bonus points: write a GUI for this

                            See this link for more info: undelete a just deleted file on ext4 with extundelete.






                            share|improve this answer


















                            • 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














                            up vote
                            4
                            down vote













                            connect drive through external interface



                            1. mount

                            2. umount /dev/sd*

                            3. extundelete --restore-all /dev/sd*

                            4. results go to home folder on boot drive

                            5. bonus points: write a GUI for this

                            See this link for more info: undelete a just deleted file on ext4 with extundelete.






                            share|improve this answer


















                            • 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












                            up vote
                            4
                            down vote










                            up vote
                            4
                            down vote









                            connect drive through external interface



                            1. mount

                            2. umount /dev/sd*

                            3. extundelete --restore-all /dev/sd*

                            4. results go to home folder on boot drive

                            5. bonus points: write a GUI for this

                            See this link for more info: undelete a just deleted file on ext4 with extundelete.






                            share|improve this answer














                            connect drive through external interface



                            1. mount

                            2. umount /dev/sd*

                            3. extundelete --restore-all /dev/sd*

                            4. results go to home folder on boot drive

                            5. bonus points: write a GUI for this

                            See this link for more info: undelete a just deleted file on ext4 with extundelete.







                            share|improve this answer














                            share|improve this answer



                            share|improve this answer








                            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












                            • 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










                            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






                            share|improve this answer
























                              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






                              share|improve this answer






















                                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






                                share|improve this answer












                                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







                                share|improve this answer












                                share|improve this answer



                                share|improve this answer










                                answered Jun 10 at 4:21









                                intika

                                1605




                                1605




















                                    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.






                                    share|improve this answer
























                                      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.






                                      share|improve this answer






















                                        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.






                                        share|improve this answer












                                        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.







                                        share|improve this answer












                                        share|improve this answer



                                        share|improve this answer










                                        answered Jun 21 '13 at 14:46









                                        unxnut

                                        3,3422918




                                        3,3422918




















                                            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.






                                            share|improve this answer




















                                            • 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














                                            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.






                                            share|improve this answer




















                                            • 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












                                            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.






                                            share|improve this answer












                                            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.







                                            share|improve this answer












                                            share|improve this answer



                                            share|improve this answer










                                            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
















                                            • 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










                                            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!






                                            share|improve this answer
























                                              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!






                                              share|improve this answer






















                                                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!






                                                share|improve this answer












                                                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!







                                                share|improve this answer












                                                share|improve this answer



                                                share|improve this answer










                                                answered Sep 30 '14 at 19:08









                                                NTT

                                                172




                                                172















                                                    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?


                                                    Popular posts from this blog

                                                    How to check contact read email or not when send email to Individual?

                                                    Displaying single band from multi-band raster using QGIS

                                                    How many registers does an x86_64 CPU actually have?