Recently I've encountered a problem, and now I would preciate any help about being able to undelete files. My /var filestructured is mounted at /dev/hdc1 Part of my /etc/mtab looks like this: /dev/hdc1 /var ext3 rw 0 0 I'm using the e2fsprogs-1.23-2 package currently installed with Redhat 7.2 So, could anyone give me a hint of how things could be done to find deleted inodes? I've tried to use debugfs , but I suspect this only helps if I'm using ext2. Or does they support ext3 too? I know.. backup is everything, but the reason I'd like to do this is that I know that last saturday at 9:35 am, the logs were most likley altered to cover up after a system break-in. The original logs could have been copied before this and therefor finding out deleted inodes could be of a great importance. A backup was obviously not done by these files during this event.. (shame on them!) Thanks, // Stefan!
On Mon, Feb 18, 2002 at 10:41:27PM +0100, NovaLand wrote:> Recently I've encountered a problem, and now I would preciate any help > about being able to undelete files. > > My /var filestructured is mounted at /dev/hdc1 > Part of my /etc/mtab looks like this: > /dev/hdc1 /var ext3 rw 0 0 > > I'm using the e2fsprogs-1.23-2 package currently installed with Redhat 7.2 > > So, could anyone give me a hint of how things could be done to find > deleted inodes? > > I've tried to use debugfs , but I suspect this only helps if I'm using > ext2. Or does they support ext3 too?Yes, it will look exactly like ext2 when it is unmounted. Just to repeat: don't run debugfs on an unmounted file system!> > I know.. backup is everything, but the reason I'd like to do this is > that I know that last saturday at 9:35 am, the logs were most likley > altered to cover up after a system break-in. The original logs could > have been copied before this and therefor finding out deleted inodes > could be of a great importance. > > A backup was obviously not done by these files during this event.. > (shame on them!)They could've overwritten the files first too, and then debugfs would not be able to help... Does ext2 try to use the same blocks after a truncate call? even if it didn't, the inode would list the *new* blocks and not the old ones. Assuming: o truncate o overwrite o delete if they tried: o overwrite (no truncate) o delete you're fscked unless you know how to read overwritten areas on a hard drive... Mike
On Mon, Feb 18, 2002 at 10:41:27PM +0100, NovaLand wrote:> Recently I've encountered a problem, and now I would preciate any help > about being able to undelete files. > > My /var filestructured is mounted at /dev/hdc1 > Part of my /etc/mtab looks like this: > /dev/hdc1 /var ext3 rw 0 0 > > I'm using the e2fsprogs-1.23-2 package currently installed with Redhat 7.2 > > So, could anyone give me a hint of how things could be done to find > deleted inodes? > > I've tried to use debugfs , but I suspect this only helps if I'm using > ext2. Or does they support ext3 too?You can use debugfs, but unfortunately, the way ext3 works the allocated blocks in the deleted inodes get zapped when the inode is deleted, unlike in ext2. This means that the recovery tricks that work when the filesystem is mounted as ext2 don't work under ext3. It would be really nice to fix this, but It Would Be Hard. I'm thinking about ways in which the data saved by e2image could be used to recover deleted files (assuming that the filesystem metadata is regularly being backed up via e2image), but while it oculd be done, it's a Mere Matter of Programming that hasn't been done yet. And in any case, it won't be able to recover the filename -> inode number mapping information. (You could save that information using e2image -r, but that's a fairly slow and painful operation.) - Ted
On Feb 18, 2002 22:41 +0100, NovaLand wrote:> Recently I've encountered a problem, and now I would preciate any help > about being able to undelete files. > > My /var filestructured is mounted at /dev/hdc1 > Part of my /etc/mtab looks like this: > /dev/hdc1 /var ext3 rw 0 0To start with, you should leave e2fsck checking enabled for your ext3 filesystems. If there is ever a filesystem error, the in-kernel recovery code cannot repair it, unlike e2fsck. If the periodic e2fsck forced checks bother you, change them with tune2fs (-c and -i options) to something you can live with. As people have seen in the past, disks, kernels, memory are not perfect, so you should still check your filesystems every 6 months or so.> So, could anyone give me a hint of how things could be done to find > deleted inodes?The way that ext3 deletes them makes it impossible to do this, unlike ext2. It is a problem that the ext2 developers are aware of, but it isn't necessarily easily fixed.> I know.. backup is everything, but the reason I'd like to do this is > that I know that last saturday at 9:35 am, the logs were most likley > altered to cover up after a system break-in. The original logs could > have been copied before this and therefor finding out deleted inodes > could be of a great importance.Well, if this is the case, then having the old logs will probably not help you. I would reinstall the system from scratch, and restore your data from backup. If you don't want to do that, at least reinstall your OS from scratch, replace your binaries, and audit any startup scripts, server config scripts, etc for new holes. Cheers, Andreas -- Andreas Dilger http://sourceforge.net/projects/ext2resize/ http://www-mddsp.enel.ucalgary.ca/People/adilger/