Slashdot Mirror


Disk Repair Tools for Linux?

Sujes asks: "Despite all the hype about how Linux is more stable or better than Windows, it seems ironic that nobody talks about any kind of disk/file repairing tools on Linux. In fact, I can't even restore a file that is accidentally or otherwise lost by a simple rm command. Does anyone know where should I look for these valuable recovery tools, if such things even exist on Linux?"

12 of 25 comments (clear)

  1. Heres a fix by Anonymous Coward · · Score: 2

    alias rm = 'rm -i'

    tada.

    More usefully, there is a util somewhere that has a libc wrapper that turns unlink() into mv(file,~/.trash/file) and has a reaper daemon.
    Don't rember it's name..

  2. The ext2 "undeletion" tools are at... by Ineversaidthat · · Score: 2

    ... http://www.praeclarus.demon.co.uk/tech/e2-undel/ This is a collection of programs and procedures that (as previously mentioned) offer no guarantees, but should certainly be a part of any admin's toolkit. Not just for problems, but for the educational value as well. Good stuff!

  3. rm really _should_ delete by Matts · · Score: 2

    I personally don't want an rm command to be undoable. Ever. If I'm using what I consider a secure OS, I need to consider deletes also secure. That means remove, and wipe over with \0's. Think of the security consequences of your sysadmin being able to access those "for your eyes only" documents that you decided to delete for safety, only to be undeleted...

    IIRC NT actually takes this approach too.

    As far as disk recovery tools go - that's what fsck does. It just comes with the OS - we don't consider this a tool that you should have to purchase separately.

    --

    Matt. Want XML + Apache + Stylesheets? Get AxKit.
    1. Re:rm really _should_ delete by ebenson · · Score: 2

      That means remove, and wipe over with \0's.

      I don't think rm does this by default, there is a ext2 attribute to cause deleted files to be securely deleted but I am not sure if its actually implemented. the chattr man page says only c and u are unimplemented (compress and undeleteable) so maybe it is...

      from man chattr:
      When a file with the `s' attribute set is deleted, its blocks are zeroed and written back to the disk.

      this is not exactly the most convenient way to go if you want every file you delete to be securely deleted however, in that case exchanging rm for wipe is probably what you want.

      --
      blah blah blah

      --
      Ethan
  4. Can't undelete by retep · · Score: 3

    Due to the design of ext2fs, and *many* other filesystems, there is no way to undelete a file. In dos the directory entry would be left behind and you *might* be able to undelete your file, *if* the file wasn't fragmented. Just about any other good filesystem such as ext2fs, NTFS, etc. quickly reclaims the space taken up from deleted files for performence and doesn't save the directory entry.

    If you do delete a file you might be able to recover it, but there aren't many ways to automate ext2fs undeletion. For help see the Ext2fs-Undeletion mini-HOWTO.

  5. Re:May require ext2fs design changes by andrewhw · · Score: 2

    I done the following to solve this problem in the past (not actually with ext2, but the solution works for all fs's)

    If you know "keywords" in the data (i.e.; you have some means of recognizing your data from context), then you ccan pretty easily do the following (in a shell script -- you will want to tinker a bit):

    • use 'dd' to read the data off of the raw partition (i.e.; don't mount it, just use
      • /dev/fd<A><N>
      or
      • /dev/sd<A><N>
      -- wherever your disk is. If the partition table is also hosed, you can just use omit the partition id, and you will get the whole disk
    • set the blocksize (e.g. bs=4k) to be the blocksize of the fs you created (if you rememeber it)
    • pipe into "split" to divvy the result into blocksize (or other handy size) chunks
    • if you are looking only for text (by far the easiest to recover) you can get rid of the extra info usings strings -a. You can do this either before or after the split, but be aware that after using "strings", the blocksize will have no relation to the blocks you are getting from "split"
    • use "grep" to determine if any of your keywords are in a block. I usually built a list of occurances, so that after this step I can rank the blocks as most likely to be part of the file(s) I want.
    • This should give you a set of blocks which you can stick together in files. I have used this method to recover a couple of things; most notably a novel my sister was in the process of writing (without a backup -- she knows better now).

  6. Ask about backup/restore or version control by hamjudo · · Score: 2
    There are many ways to accidentally destroy files. Overwriting a file with the wrong stuff is just as bad as removing the file.

    It isn't a backup system, it is a restore system. All people care about is if the restore works. Backups are important, because restore can't work without them.

    I use different mechanisms for recovering old files. I use RCS for some things, because that gives me a changelog back to the birth of the file. I only use it on files that I knew were important when I created or changed them. I use rsync to keep a current copy of the whole system. This backs up things that I didn't know were important until I destroyed them.

  7. better rm... by llando · · Score: 2

    If you are frightened of unsecured deleting, why you don`t use a simple dd-command ala dd if=/dev/null of=file? 100% should be deleted

  8. Here's another... by Tony+Hammitt · · Score: 2

    #!/bin/sh

    if [ $1 = "-rf" ]; then
    &nbsp&nbsp&nbsp&nbsp /bin/rm $@
    else
    &nbsp&nbsp&nbsp&nbsp if [ $HOME/.trashcan = $PWD ]; then
    &nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp /bin/rm $@
    &nbsp&nbsp&nbsp&nbsp else
    &nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp stamp=`date '+%j.%H%M%S'`
    &nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp echo "moving files to ~/.trashcan/"
    &nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp for arg in $@; do
    &nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nb sp&nbsp&nbsp filenm=`echo $arg | sed 's/\//V/g'`
    &nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nb sp&nbsp&nbsp mv $arg $HOME/.trashcan/$stamp.$filenm
    &nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp done
    &nbsp&nbsp&nbsp&nbsp fi
    fi


    Then just name this something like 'remove', put it on your $PATH and make an alias/script called 'dump' that 'rm -i $HOME/.trashcan/*' then alias rm remove (assuming tcsh alias syntax).

    This has the advantage of being able to see where the file came from if you interpret the 'V' for '/'. It's a little slow, but if you're concerned about accidentally deleting a file, it helps a lot.

  9. ReiserFS by Cris · · Score: 2

    I'm sad to see no mention of this yet--the Reiser filesystem offers exponentially better performance (I've done some nonofficial benchmarking to back up their claims) and more importantly offers journaling. As far as disk integrity goes, a journaling file system (unless it REALLY sucks) is unaffected by crashes because every change is journaled. Therefore the need for disk repair tools, etc is negligible (though there are a few maintenance tools). In high performance situations, Reiser is almost the no-brainer choice as far as FS on linux go (though at the moment you cant directly boot from reiser, you can make everything but your little /boot partition reiser by hand. People are working on a more elegant solution I'm told). But aside from that, it's also a pretty sound decision for the typical server to use. Stable, lightning fast and reliable...

  10. Undeleteing is not Disk Repair by SEWilco · · Score: 2
    Disk repair is not recovering a deleted file. Disk repair is recovering files/directories after filesystem damage.

    If you want to recover deleted files, you should ahead of time be using one of the methods which others have mentioned...or be using a filesystem/database which allows recovery of past contents (ie, store everything in something like CVS and decide how long to retain until permanent deletion).

  11. simple, but effective by Cheeze · · Score: 2

    strings /dev/hda | less


    where hda is the device name.


    this works, but it's not too pretty. i've recovered about 50 megs of e-mail from a fat32 drive this way.

    --
    Why read the article when I can just make up a snap judgement?