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?"
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..
... 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!
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.
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.
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):
- /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 diskThis 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).
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.
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
#!/bin/sh
/bin/rm $@ /bin/rm $@ b sp   filenm=`echo $arg | sed 's/\//V/g'` b sp   mv $arg $HOME/.trashcan/$stamp.$filenm
if [ $1 = "-rf" ]; then
    
else
     if [ $HOME/.trashcan = $PWD ]; then
        
     else
         stamp=`date '+%j.%H%M%S'`
         echo "moving files to ~/.trashcan/"
         for arg in $@; do
         &n
         &n
         done
     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.
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...
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).
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?